Gpc

gpc@gnu.de

5400 discussions

Re: Quo vadis, GPC?
by samiam＠moorecad.com 28 Jul '10

28 Jul '10

Frank, Some brief notes on your presentation "Quo vadis, GPC" (Where is GPC going). I'd of sent it direct, but I note your email is not working. First, I also considered, and was strongly suggested, to use GCC as a backend for my compiler. I rejected this idea because, primarily, of the very tight coupling between the front and back ends of GCC. This is in contrast to the well developed intermediate code coupled systems outside of GCC. The other issue is the, frankly, hostile attitude of the GCC folks towards Pascal. Fortran and other compilers are distributed with GCC and get better support from the GCC group. I can't help but think that this comes from the C group perception of Pascal as a rival, which it used to be but is no longer. As for making GPC a front end for another compiler, I can't think of a better way to insure that GPC dies quietly. Virtually all of the "cascade" compilers, including Cfront, had severe difficulties, including becoming unnaturally coupled to one particular backend, and angering users by giving errors from the underlying compiler that the front end didn't catch. C++ became a success because Stroustrup moved quickly away from Cfront and onto a true compiler for C++. GPC started out with a big advantage due to having a high quality back end with wide implementation. However, you detail well the unseen costs of that, including a moving target back end specification, inability to write the compiler in its own language, etc. Pascal scores low as a common implementation language, but as you detail, most of this is because of a movement to interpreters and away from true compilers. Although this is stated to be "because of ease of development", I believe in large part this is a reaction to the difficulties of C/C++ development, which is directly traceable to the complexity of the language and the difficulties with debugging a language totally lacking in basic type security. I think nothing underlines this more than Anders' move to Microsoft and C#: Anders went from taking a language designed around type security (Pascal) and tearing away its type security, to taking a language designed around a lack of type security (and proud of it) C, and adding type security to that. I completely agree with your diatribe on automatic destructors. I choose automatic (and anonymous) constructors and destructors for the language Pascaline (a highly extended version of Pascal) because I believed it was necessary for the compiler to both control when, and in what order, the constructors and destructors are called. I also believe (as shown in Java and C#) that classes should be treated as code structuring constructs and NOT as "extended records", and that both static and dynamic objects have their uses. In Pascaline, classes are expressed as modules which can be instantiated, and fit within modules in program structure (programs are a series of modules which may contain classes). For more on that, I invite you to look over the Pascaline specification: http://www.standardpascal.org/standards.html I looked at templates for Pascaline, and I used your exact example to evaluate it, that is, general handlers for list structures. However, I came to the conclusion that this was also the paramount example for classes, and in fact classes are an example of a highly structured system of typing that reduces the need for the highly unstructured method offered by templates (which by the way, Wirth is on record as saying was not such a hot idea). Although I am not sure I see the sense of your basic argument (interest in GPC is falling off, so lets rewrite it). I would say it makes equal sense to simply start moving parts of GPC into its own language and away from C. If you were to write a code generator to replace the back end, in Pascal, you would both be independent of GCC and much farther along on your goal of a GPC rewritten in its own language. Cheers, Scott Moore

2 1

Re: Quo vadis, GPC
by John Gordon Ollason 28 Jul '10

28 Jul '10

I shall begin by thanking all the people who have contributed to GPC which I have used as my programming language of choice for algorithms since I moved to Linux Red Hat Version 5.2. I am now retired and apart from the occasional recreational programming, a couple of years ago I wrote a Sudoku solver when I was annoyed that I couldn't solve a particular grid, I very seldom need a Pascal compiler. I was an ALGOL 60 programmer before I became a Pascal programmer, and then, when I had to learn C I was horrified by the ad hoc nature of the language. But ad hoc seems to be the favoured strategy of the time, and as far as I know very few people learn Pascal now, and therefore the base of users is ageing. Without a thriving population of young programmers the language will die, and I suspect that the formal virtues of a language in the ALGOL tradition are not being transmitted, and perhaps new programmers are not being equipped to recognize the admirable qualities of Pascal. I suggest, therefore, that no substantial development of GPC would be cost effective unless there were a large base of users of the language, and that the first priority should be to determine the number of current users of the language and to estimate its expected future use. My own pessimistic assessment may be mistaken; I hope it is, but it would make sense to find out before committing a substantial amount of effort in further development of a language that is only used by a small minority of programmers. John O.

1 0

Re: close(file); always necessary??
by samiam＠moorecad.com 19 Jun '10

19 Jun '10

Hence the reference count stuffs. I did a paper analysis once, I decided that: 1. To do true automated storage recycling, you have to track each pointer leaving scope, which means that you have to know where every pointer is. 2. Be ready to reference count each pointer, that is, each copy operation increments the reference count, and each dynamic entry gets a reference counter that is initially one for the pointer that is returned. 3. Decrement the reference counter each time any pointer leaves scope. 4. produce an error if the programmer attempts to free a non-zero referred pointer. 5. The whole thing generates headaches. Seriously, it is quite doable with Pascal, but generates a lot of overhead. Each data structure needs a template for the contained pointers, and every data structure leaving scope or freed must be analysed for contained pointers, and those pointers decrementing reference counts. Wirth also described this scheme, although I don't think he ever tried it. I have thought about implementing it primarily to shut people up, i.e., lack of automated storage collection "is a problem with old languages like Pascal". It isn't, the price paid for reclaimation overhead is the same as Java or other languages, we are primarily burdened by users who expect true compiled performance code. Scott -------- Original Message -------- Subject: Re: close(file); always necessary?? From: Frank Heckenbach <ih8mj(a)fjf.gnu.de> Date: Fri, June 18, 2010 2:56 pm To: gpc(a)gnu.de samiam(a)moorecad.com wrote: > Then that would leave you pretty close to > automatic dynamic storage recycling, no ? Partly. When a pointer variable goes out of scope, we cannot automatically dispose it, since copies may exist. Fully automatic storage recycling still requries full-blown reference counting or garbage collection, AFAICS. Frank -- Frank Heckenbach, f.heckenbach(a)fh-soft.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8

2 1

Re: close(file); always necessary??
by samiam＠moorecad.com 18 Jun '10

18 Jun '10

2 1

Re: close(file); always necessary??
by samiam＠moorecad.com 15 Jun '10

15 Jun '10

2 1

close(file); always necessary??
by Rugxulo 15 Jun '10

15 Jun '10

Hey, In non-standard Pascal mode, does it matter if I explicitly close the file or not? E.g., "close(file);", is that done automatically or is it implementation defined? (I'm 99% sure DOS always closes files upon exit.) I'm just wondering if that's a fair assumption for Linux, etc. (though I kinda doubt it).

3 2

3 points
by spir 14 Jun '10

14 Jun '10

Hello, I'm am amateur programmer, new to gpc and rather new to Pascal as well. I wonder whether this list is a proper place to find help in learning the language, and in using it for a few projects of mine. If yes, then below is a first series of diverse questions. I will have some more as I discover the language (including some stupid ones, certainly ;-). [Note: I have a candidate answer to the questions, but ask anyway to be sure, and stop wondering.] -1- writing arrays & records What is the literal notation for arrays & records? Can it apply to (a) const definition (b) var initialisation (c) var assignment? Is there a way to write back arrays & records to output (tostring(x), according to standard notation)? If not, how to write such a tool func? (super useful for learning, prototyping, testing...) Is it at all possible to write the following 'show' tool func: show(x); // 'x : 1' --> stdout show(x+1); // 'x+1 : 2' --> stdout ? (my dream debugging tool) -2- traversing collections Is there a way to traverse arrays with elements directly? (--> foreach, or Eiffel's across) Is it possible to define traversal for custom collections? -3- TP-like object system Is there more information in fpc's documentation about its object system (than chapter 6.8 in manual)? Else, are there good places online to find information about TP's object system? Denis ________________________________ vit esse estrany ☣ spir.wikidot.com

4 5

mixed comments
by Rugxulo 06 Jun '10

06 Jun '10

With apologies if this has already been mentioned. (I don't feel like searching the mailing list archives right now, and I haven't checked the test suite.) I just thought it was funny / interesting. ;-) { using GPC 20070904 / GCC 3.4.4 via DJGPP (gpc.info) : "GPC's default behaviour is (like BP) not to allow mixed comments" ... except that it allows it by ignoring it, not reporting an error (which is what was implied, or so I thought!) } { $ extended-pascal} { says "Hello, mixed!" } { $ standard-pascal} { says "Hello, mixed!" } {GPC default} { says "Hello" } {FPC default} { says "Hello" } program comment(output); begin write('Hello'); { *) write(', mixed!'); (* } writeln; end.

2 1

Fwd: findfiles syntax
by Luis Rivera 26 May '10

26 May '10

for the record, and for all those interested, ---------- Forwarded message ---------- From: Luis Rivera <jlrn77(a)gmail.com> Date: 22 May 2010 14:56 Subject: Re: findfiles syntax To: Maurice Lombardi On 22 May 2010 03:19, Maurice Lombardi <Maurice.Lombardi(a)ujf-grenoble.fr> wrote: > Luis Rivera a écrit : >> >> program FindFilesTest; >> >> uses GPC, FileUtils; >> >> type >> alphafile=text; >> var >> nameoffile: string; >> filename: alphafile; >> const >> mydir='/usr/local/'; >> >> function aopenin(var a:alphafile):boolean; >> begin if ioresult=0 then >> assign(a,trim(nameoffile)); >> findfiles(mydir,a,false,reset,nil); >> aopenin:=ioresult=0; >> end; >> >> begin >> WriteLn ('Enter file name to type: '); >> ReadLn (nameoffile); >> if aopenin(alphafile) then > [...] > Declaring the text file as filename is very confusing: this is certainly the > source of your errors: you confuse a file and its name. > > 1) a is a file, not a string (Mask) > mydir is a string (the name of the directory to search in) > 2) reset has for parameter a file, not a string. > So it expects the string containing the filename... Changing the naming conventions, trying to avoid confusing the FileName (string) with the FileContents (text), I may do the following: program AtBat; uses GPC, FileUtils; type alphafile=text; var filename: string; filecontents: alphafile; const mydir='/usr/local/'; function aopenin(var a:alphafile):boolean; var f:string; begin if ioresult=0 then f:=trim(filename); assign(a,f); findfiles(mydir,f,false,reset,nil); aopenin:=ioresult=0; end; begin WriteLn ('Enter file name to type: '); ReadLn (filename); if aopenin(filecontents) then WriteLn(filename, ' found!') else Writeln('Sorry: search failed!'); end. However, I still get the same error message... BTW: a simple, sensible way to state "DoNothing" as DirAction? > You might want to declare a FileAction procedure with a string parameter > (nameoffile): probably you would include in it the assign which is before > findfiles in your program and the reset > That's what I just tried to do! :-) > Notice that if there are multiple files found, you will have an error > because you then try to reopen a file (a) which has not been closed: > findfiles apply FileAction on all files which match Mask. Maybe I can get around that problem defining the FileAction procedure in such a way that wildcards are forbidden... > You can close the > file inside FileAction, but beware not to confuse nameoffile as a parameter > of FileAction and as a global variable: if you give two different names and > assign the global name to the parameter inside FileAction you can recover at > the end the last nameoffile found. > > PS: > > A := B = C; > is correct in Pascal, weird but correct. > Cool. Thanks for pointing that out. Cheers! -- Luis Rivera O< http://www.asciiribbon.org/ campaign

2 3

findfiles syntax
by Luis Rivera 24 May '10

24 May '10

Hello! I'm trying to implement a procedure and a function involving findfiles, which, afaik, can do path search. One thing at a time. First is the function. A sample would be --snip-- program FindFilesTest; uses GPC, FileUtils; type alphafile=text; var nameoffile: string; filename: alphafile; const mydir='/usr/local/'; function aopenin(var a:alphafile):boolean; begin if ioresult=0 then assign(a,trim(nameoffile)); findfiles(mydir,a,false,reset,nil); aopenin:=ioresult=0; end; begin WriteLn ('Enter file name to type: '); ReadLn (nameoffile); if aopenin(alphafile) then WriteLn(nameoffile) else Writeln('sorry, search failed'); end. --snip-- The compiler bites me back saying: syntax error before reset extra comma Beats my why. Thanks in advance, -- Luis Rivera O< http://www.asciiribbon.org/ campaign

5 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

Gpc