GPC's default behaviour (was: Standard Compatibility)

Fri, 4 Apr 1997 20:03:36 +0200 (MET DST)

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]

Peter Gerwinski (peter@agnes.dida.physik.uni-essen.de)