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@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal [970401] - http://home.pages.de/~gnu-pascal/ [970125]