Gpc

gpc@gnu.de

5400 discussions

Re: identifier prefixing
by Peter Gerwinski 05 Apr '97

05 Apr '97

According to Maurice Lombardi: > > I found only one annoying problem: the inexistence of prefixing of > identifiers (e.g. unit1.proc1) to avoid name conflicts. This is called "qualified identifiers", and it is planned to be implemented soon (together with Extended Pascal's `qualified' Module import and overloading of Procedures/Functions). > It also allows to redefine locally names of procedure to extend > some properties To work around: With GNU Pascal, you can have the source code of everything. It is no problem to rename the routines of Sven's "original" Graph Unit to something like "Graph_InitGraph" (thus emulating the dot by using an underscore) - or to build that additional functionality directly into the Unit you want to improve. > (I used it extensively to redefine procedures > of the graph unit to incorporate simultaneous PostScript copy of screen > functions: this allows to have either fast, screen > only drawing, or slower, with PostScript copy, programs without changing > a single line of code of the main program). Sounds great! How about adding this to the GNU Pascal "contrib" directory? I am sure there are many people (including myself) who would greatly appreciate such a "PostScript Graph Unit". > Do you plan to do this soon, later or never, so that I can make > a decision whether I need to rewrite the whole stuff with non > conflicting names or wait until you have done it (I am not in a hurry, > I can use for some time the Borland compiler). I hope that I can finish this in 1997. > Many thanks anyway for your work: I am no more afraid that > Pascal will disappear from the surface of earth due to the financial > problems of Borland. Thank you! :-) I am doing my best, and so do many people in this list. If you want to join our attempts - for example by contributing useful libraries -, be welcome! Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Compile-time switches (was: Standard Compatibility)
by Peter Gerwinski 05 Apr '97

05 Apr '97

According to Nils Bokermann: > > [...] > > I don't like the idea of a local (user) configuration file as GPC.CFG or > .gpcrc. There is a way of doing it in a makefile. If someone _needs_ a compiler > which is a borland like compiler for standard, might there be a compile-time > switch? Let's consider something like > ./configure --try-to-be-a-borland-compiler or > ./configure --use-standard-pascal. What's wrong about symbolic links `spc', `epc', `bpc' to `gpc' which make GPC strictly comply to Standard Pascal, Extended Pascal, or Borlnand Pascal (by passing the run-time parameters `--standard-pascal' etc.)? A compile-time switch would cause *much* more trouble than that. As I wrote earlier, I have the impression that most people do neither want a strinct ISO Pascal compiler nor a perfect Borland Pascal emulator, but they want an improved compiler with many extensions, BASED ON THEIR FAVOURITE COMPILER. This is * impossible, * but reality. Up to now, the default field width is the only case where Borland and ISO (more exactly: a de-facto standard based on ISO) really contradict. In all other cases Borland Pascal and ISO Pascal can peacefully coexist in one and the same compiler - which has of course to identify the dialect from the context. ONLY such cases with a REAL contradiction can, IMHO, justify a compile-time switch. And even here I am not sure ... Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Feature-Control (Was: Re: New Alpha)
by The African Chief 05 Apr '97

05 Apr '97

On Thu, 3 Apr 1997 08:46:55 +0200 (MET DST) Nils Bokermann <nilsb(a)reality.owl.de> wrote: [...] >>In case you haven't done this, can you >> introduce a .CFG file (like with Borland) where one can >> put all the command line switches that they want to use? >> The compiler will read the .CFG file before doing anything >> else, and will adjust its behaviour accordingly. I personally >> prefer this approach to using environment variables or the >> such. You can make many sample .CFG files >> (e.g., borland.cfg, extended.cfg, iso.cfg, etc) which people >> can then rename to GPC.CFG or whatever. > >Oh, No! Please don't. >Why don't we handle this like it is used in the common place way at unixish >Systems: Take a Makefile and put a line PFLAGS (is this right?) in it. There >you have all your flags, you think you need. Let's say there is a >PBORLANDFLAGS=--borland-pascal --what-in-hell-else-is-needed-for-borland >and a PMYFLAGS=--left-justified --enable-foo-warnings. >Then you can put them together to the archive your program comes with and >nobody needs to edit the GPC.CFG. > >What one might do is put sample Makerules-file(s) to the GPC distribution. Makefiles are probably wonderful. However, I don't know much about them - and I am sure that many people from a BP or Delphi background are in the same boat. I am puzzled however as to what is so bad about using a .CFG file. Can you please say what your objection is? I have seen the Makefiles that come with GPC and GCC, and, frankly speaking, a lot of the contents are like Swahili to me (meaning something which people think I ought to understand, but which I most certainly do not understand). CFG files that contain only command line switches (just as you would pass them at the command line) are simple enough for anyone to use. Makefiles seem to involve learning yet another scripting language. While this may be familiar to unix people (and I have used them before - long ago, when programming for OS/2 with GCC) a lot of Pascal programmers from non-unix and non-C backgrounds wouldn't want to touch them with a barge pole - and I am one of them! Surely, GPC could cater for everybody? (or, at least, meet them half-way). Any comments? Best regards, The Chief Dr Abimbola A. Olowofoyeku (The African Chief, and the Great Elephant) Author of: Chief's Installer Pro v3.12 for Win16 and Win32. Homepage: http://ourworld.compuserve.com/homepages/African_Chief/ E-mail: laa12(a)cc.keele.ac.uk

2 1

Re: Standard Compatibility [was: Re: New Alpha]
by Frank Heckenbach 05 Apr '97

05 Apr '97

Trying to sum up the points of this discussion and adding some of my opinions: - Both formatting ways have their place. Though programmers are used to one of them, I guess in most programs, you'll find places where one way will be easier to use, and others where the other way will be preferable. - In gpc, the switches --standard-pascal/--extended-pascal or --borland-pascal should choose the according defaults. - Additionally, switches like --[no-]clip-strings, --default-width=..., --[no-]real-blank change the defaults in these regards. - There should also be compiler options like {$CLIP+/-}, {$DEFWIDTH 12}, {$REALBLANK+/-} (?). This will be necessary if BP-ish and SP-ish programmers work together on a project, and want to build their program with --automake. And it can be convenient for a single programmer to change it for different procedures (see above). - The default behaviour without any switches or options can be like standard Pascal in this regard. (I'm saying this although I'm coming from BP.) Sven, those BP programmers who want to change smoothly to gpc will use --borland-pascal anyway, so there should be no problems with this one. - A way to read in configuration files (like "gpc @gpc.cfg") seems good (in addition to environment variables and command line options). Even if gpc doesn't read in a config file by default, it should be no problem to set an alias accordingly (BTW, even modern DOSes support something like alias in the form of DosKey...) - Putting those flags in a makefile is also an option, but only if one is to use makefiles at all. Personally, I don't like makefiles, and I think Pascal programs don't need makefiles, since all the dependencies between modules are there in the code (unlike C). Therefore, I'd like to be able to compile any Pascal program with simply "gpc --automake progname.pas". Any compiler options should be in the source (at least there should be a way to do so). BTW (not quite to this topic): Is there any reason why the default output file is called "a.out" (or "a.exe" with DOS) - other than historical reasons? Wouldn't it make more sense to default to the base filename of the main program, in order to save programmers from typing "gpc -o x x.pas"? - Naming the program gpc, spc, epc and bpc seems like a sensible way for Un*x, but on systems that don't support either hard or symbolic links (aka DOS), it would mean 4 separate binaries - probably not a good solution there (although those DOS users who want to do only Borland style could rename gpc.exe to bpc.exe). So this could be one, but not the only, way to choose the defaults. Note: there would be a difference between gpc (GNU Pascal with all the extensions) and spc (standard Pascal only), perhaps not in the question of output formatting, but in other regards. -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

3 2

identifier prefixing
by Maurice Lombardi 05 Apr '97

05 Apr '97

I am moving from Borland Pascal (which I have used for years) to GNU pascal (DJGPP port) because I have no more hope that they will improve their DOS compiler (to 32bits, optimisation). Many things work fine. I found only one annoying problem: the inexistence of prefixing of identifiers (e.g. unit1.proc1) to avoid name conflicts. This is a very useful feature because it makes units of different origins truly independants. It also allows to redefine locally names of procedure to extend some properties (I used it extensively to redefine procedures of the graph unit to incorporate simultaneous PostScript copy of screen functions: this allows to have either fast, screen only drawing, or slower, with PostScript copy, programs without changing a single line of code of the main program). Do you plan to do this soon, later or never, so that I can make a decision whether I need to rewrite the whole stuff with non conflicting names or wait until you have done it (I am not in a hurry, I can use for some time the Borland compiler). Many thanks anyway for your work: I am no more afraid that Pascal will disappear from the surface of earth due to the financial problems of Borland. -- Maurice Lombardi Maurice.Lombardi(a)ujf-grenoble.fr Laboratoire de Spectrometrie Physique | Universite Joseph Fourier de Grenoble BP 87 | tel: (33) 04 76 51 47 51 38402 Saint Martin d'Heres Cedex FRANCE | fax: (33) 04 76 51 45 44

1 0

Re: New Alpha
by Frank Heckenbach 05 Apr '97

05 Apr '97

> write ('There are ', items:1, ' items') > > >Or does this "clipping" only apply to strings? > Clipping only applies to strings. I see, fine. > >But then again, how would you do "You name is Phil."? > >Do you have to "write(s:Length(s))" or such? > write ('You name is Phil.') :) Err... well, I meant 'Phil' was the value of a string variable. I thought this would be clear. > In standard Pascal there are no string schema types like extended Pascal, > but in extended Pascal "write(s)" is identical to "write(s:length(s))". Ok, then, if I got this right, you have to do write(num_var:1) and write(string_var) for output without spaces, whereas write(num_var) and write(string_var:1) both don't work this way. This seems a bit inconsistent and confusing to me. I see that your programs rely on this way, but my programs rely on BP's way, and I don't think there's anything worse with BP's way than the standard's way. So, obviously, gpc needs to support both ways. > "Strings" in standard Pascal are typically an "array [1 .. n] of char". > The programmer then needs to keep track of how many of the n characters > are valid. Then the write statement would look like "write (s:sizeofs)". This explains to me why this clipping is needed in standard Pascal. However, I really don't want to use hand-made strings in my programs, I really could stand a little more comfort... :-) -- Frank Heckenbach, Erlangen, Germany heckenb(a)mi.uni-erlangen.de Turbo Pascal: http://www.mi.uni-erlangen.de/~heckenb/programs.htm Internet links: http://www.mi.uni-erlangen.de/~heckenb/links.htm

5 7

Configuration files (was: Standard compatibility)
by Peter Gerwinski 04 Apr '97

04 Apr '97

According to Jan-Jaap van der Heijden: > > [...] > > 1) A config file already exists and it is called `specs' (`specs.gpc' if > you're using the djgpp version). It is shared among all members of the GNU > compiler family. Introducing a second, gpc specific config file doesn't > make sence IMHO. I agree in principle, but I just had a look at that `specs' file. It seems to be written in some alien dialect for me, and the info documentation does not say anything about its format. If there is an easy way to put GPC options into this `specs' file we should document is. This would cover some applications of a `gpc.cfg' file, but not all: `specs' is a global configuration file while `gpc.cfg' would be local. > 2) GPC doesn't have to be modified to implement the @file trick. This is > a DOS "feature" to overcome DOS commandline-length limitations. > > [...] Yes, but this does not work on non-DOS platforms. I didn't find it in the GPC source, so it seems that we cannot enable it for other platforms (assuming for the moment that we want to do that). > 3) If you are a delphi/tp user and want point-and-click userfriendlyness, > I suggest you install RHIDE. Will look very familiar. Can even write one > of those dreaded makefiles for you ;-) I agree. The RHIDE can provide menus for all command-line options. > > - Putting those flags in a makefile is also an option, but only if one > > is to use makefiles at all. Personally, I don't like makefiles, and I > > think Pascal programs don't need makefiles, since all the dependencies > > between modules are there in the code (unlike C). Therefore, I'd like > > to be able to compile any Pascal program with simply > > "gpc --automake progname.pas". Any compiler options should be in the > > source (at least there should be a way to do so). > > Answered above (I hope) However I have planned to make it possible to put all compiler options (including `--automake' :) into the source, so you will be able to compile any Pascal program just with "gpc progname.pas". > > BTW (not quite to this topic): Is there any reason why the default > > output file is called "a.out" (or "a.exe" with DOS) - other than > > historical reasons? Wouldn't it make more sense to default to the > > base filename of the main program, in order to save programmers from > > typing "gpc -o x x.pas"? > > Besides hisotorical reasons, it is ofen used in automated testsuites > (in a unix environment) where the compiler is run on a large set of source > files. EMX defaults to compile `x.pas' to `x.exe'. RHIDE does "gpc -o x.exe x.pas" automatically. On my Linux box, I use a shell script gpc --some-options --automake="--some-more-options" -o $1 $1.pas -lmylibs which does both: specify the name of the executable and pass all options to the compiler. > I'm currently experimenting with a seperate compiler pre-driver (like g++ > and f77) which can set the language switches when invoked as `bpc' or > `gpc' etc. It's about 15K which is small compared to the 1.5M of gpc1, > even if you install it 4 times because your OS lacks symlinks. In fact DJGPP supports symbolic links on DOS. But anyway, Jan-Jaap's solution will - hopefully - eliminate a lot of trouble. Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

GPC's default behaviour (was: Standard Compatibility)
by Peter Gerwinski 04 Apr '97

04 Apr '97

According to Frank Heckenbach: > > - The default behaviour without any switches or options can be like standard > Pascal in this regard. (I'm saying this although I'm coming from BP.) > Sven, those BP programmers who want to change smoothly to gpc will use > --borland-pascal anyway, so there should be no problems with this one. Here I disagree. (Details below.) (I am also coming from BP, but I am disappointed about Borland, so I consider myself to be more-or-less neutral. ;-) > - A way to read in configuration files (like "gpc @gpc.cfg") seems good (in > addition to environment variables and command line options). Even if gpc > doesn't read in a config file by default, it should be no problem to set > an alias accordingly (BTW, even modern DOSes support something like alias > in the form of DosKey...) I agree, even though there is `specs.gpc'. However there are technical problems to implement "gpc @gpc.cfg" in a clean way, so let's first see whether we can do some magic with `specs.gpc' and such. > [...] > Note: there would be a difference between gpc (GNU Pascal with all the > extensions) and spc (standard Pascal only), perhaps not in the question > of output formatting, but in other regards. Yes. We would end up with several different compilers - which are in fact all the same with different (implicit) command-line options. However I guess that nobody will use anything besides `gpc', the default GNU Pascal compiler: * Those who vote for more Borland Pascal support in GPC don't really want an emulation of Borland Pascal 7.0. They are looking out for something like a BP 8.0, a "natural" successor of BP 7.0. Since Borland clients are used to new features appearing with each release, they won't restrict themselves to `--borland-pascal'. Instead, they want to have GPC's default behaviour to be Borlandish enough to feel at home. * As far as I could see from this discussion, those who favor ISO Pascal (in particular: ISO 10206 Extended Pascal) do not want either to have just ISO, but they want to have a compiler which adds "natural" extensions to the ISO Standard. So they will also call GPC as `gpc', not as `epc', and want to have GPC's default behaviour similar enough to other ISO compilers to feel at home. The only solution is to make GPC a chameleon: The default behaviour must be acceptable by both sides, and there must be compiler switches to tune GPC to make everybody feel at home. As far as I have learned during my work on GPC, Borland Pascal and Extended Pascal can peacefully coexist - much better than you would expect when trying to compile a BP program with EP or vice versa. Most differences are missing features of one compiler in the other one. For example, BP does not have `Complex' while EP does not have `Word'. Okay, it's no problem to have both data types in one compiler. In fact this "field width" story is the first case where we have an actual contradiction. The most funny thing is that BP does not contradict to the ISO Standard but to some de-facto standard among ISO Pascal compilers. Whenever I will encounter such a contradiction I will * introduce a new command-line switch (because there will be programs relying on a specific behaviour of the compiler) and * make the "best" solution GPC's default behaviour. What "best" means must be discussed on this list. I do *not* automatically consider ISO compliance to be "best" (because the ISO Standard is the official standard, accepted by many companies which provide compilers for it); *nor* do I automatically consider Borland compatibility to be "best" (because BP is the world-wide de-facto Pascal standard on the PC which is in turn the de-facto standard for computers). Both standards must be checked whether they "combine the clarity of Pascal with powerful tools suitable for real-life programming" as stated in the GPC documentation to be the purpose of GNU Pascal. In cases where it is not clear which way is better, ISO will be favorized. I am glad that up to now there was no decision "against" ISO. Thanks to all of you for your help to find out what is "best" (or at least "not too bad") in the case of field widths. If there are no strong objections against my plan, I would like to close that discussion now and to implement all those nice switches I have promised in my other mail. Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125]

1 0

Relevance of Borland Pascal (was: Standard compatibility)
by Peter Gerwinski 04 Apr '97

04 Apr '97

According to Kevin A. Foss: > > I have to admit I'm in favor of defaulting to ISO standard behavior, but > that is just my personal preference. I'm mainly concerned with the last > comment... is it true that 'thousands of dos-pascal-programs' will be > ported to linux'? Yes. There is an incredible number of Borland Pascal programmers out there. Just watch news://comp.lang.pascal.*: most questions, even those posted to comp.lang.pascal.ansi-iso, concern Borland Pascal. Some of them (~50%???) happily change to Delphi and move to Windows 95 without ever looking out of the (MS-) Window. Some others (which I would consider the best ones;) want to try Linux and are looking out for a Pascal compiler. > I don't see a majority of the DOS-based TP programs > being all that useful, Of course not all of that is useful, but enough to make it worth the effort. In addition: think of games. Not useful, but they can make Linux more attractive. Many games are written in Borland Pascal for DOS. I have heared of game authors who would be happy to have a 32-bit Pascal for DOS. If they see that there is a compiler which supports Linux as well, they will give Linux a try. > or all that many TP programmers perceiving a need to > port their software to gpc. Granted there was a lot of good software > written with TP and which should be ported, but I think your numbers are > over stated. I think these numbers are realistic. (Just what I guess from conversation with other programmers.) > The comment also begs the question. is gpc's role to provide a facility for > porting 10 year old DOS programs or for the creation of new programs? I > would think primarily the latter and that decisions on gpc's defaults > should serve that end. GPC is for the creation of new programs. It should provide facilities to port existing programs (all those --command-line-switches), but this should not become our primary goal. This also guided my decision in favour of a default field width of 0: Most programs written today don't sequentially read in columns of numbers, process them and put out some other columns of numbers. Today's programs process strings and interact with the user; most numbers appear in sentences like Frank's "There are 7 items." Thus GPC's default behaviour should support the latter one; those of us who need the first one (including myself, sometimes) are experienced enough to change GPC's default by configuration, a command-line switch, or even an explicit field width specification. For programs intended to be portable the latter method is the most secure one anyway. Greetings, Peter

1 0

Standard Compatibility: my plans
by Peter Gerwinski 04 Apr '97

04 Apr '97

Hi, everybody! Here are my plans for GPC's default `write'/`writeln' behaviour: * I will fix that bug which suppresses output when the field width is 0. * String clipping will be ON by default, thus GPC will follow ISO and UCSD, not Borland. It can be switched OFF either with `--borland-pascal' or `--delphi', or with a separate switch `--no-clip-strings'. * Field widths are 0 by default. This does comply to the ISO Standard Specifications AND corresponds to the behaviour of UCSD Pascal, Borland Pascal, and other PC Pascal compilers. This default can be changed using `--field-widths=12,24,6' (for Integer, Real, Boolean fields) which can be given either when compiling a Pascal source file ("locally") or when configuring GPC (making the default widths "global" for a site). * Although default field widths of 0 are correct by ISO, there seems to be a de-facto standard among ISO Pascal compilers that field widths must ensure at least one blank in front of Integers and Reals. For this reason, `--standard-pascal' and `--extended-pascal' will imply default field widths which will make GPC behave like other ISO Pascal compilers. * If `--field-widths' is given without arguments, it will make the field widths big enough to ensure at least one blank in front of numeric values. * I will try to make it possible to pass these command-line options as compiler directives, e.g. (*$field-widths=12,24,6*). Having this, you can write programs which will behave independently of command-line options given to the compiler. This possibility will also cover most applications of a "GPC configuration file". Okay, this will take some time to finish. I hope that everybody can live with this. Yours, Peter Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski(a)uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125]

2 1

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