New Alpha_(re)

Thu, 3 Apr 1997 19:55:14 +0200 (MET DST)

According to Frank Heckenbach answering to a mail by Phil Nelson:
> 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.

To me, too.  That's why I prefer Borland's way to default to a width of
0 (or 1 in the above example) if nothing was specified (which does not
contradict the standard, BTW), and to treat string values just like all
the other ones, i.e. without clipping.

> 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.

So it's okay that "gpc --borland-pascal" does switch off string clipping,
while "gpc --standard-pascal" or "gpc --extended-pascal" turns it on.
There must also be a pair of separate switches, e.g. "--clip-strings" and
"--no-clip-strings", to make this decision independent of the selected
Pascal dialect.

  (*** Does anybody know how UCSD behaves here?  I don't want to dig
  out my old Apple //e in order to check this. ***)

Now what about default field widths?  The ISO Standard allows this
to be implementation-dependent.  If we just take Borland's method it
still complies to the standard, so there is no a-priori reason to make
this change at all.  However it seems to be a de-facto-standard that
ISO Pascal compilers have default field widths that are wide enough
to ensure that numeric values are always output with leading spaces.
Thus `--standard-pascal' and `--extended-pascal' should imply such wide
field widths.  Of course there must be a separate switch for them, for
example "gpc --field-widths=12,24,6" (for Integer, Real, Boolean values).

The above does not clarify how GPC's default behaviour should be.
IMHO Borland's method is more logical than what most Standard Pascal
compilers do.  However the only true contradiction between Borland and
ISO in this context is string clipping which only occurs in very rare
cases (at least in my programs).  Thus I could live with string clipping
being "on" by default.  Concerning field widths, it does not contradict
ISO Standard to follow Borland, so we should do that.  (Remember that
`--borland-pascal' turns string clipping off and that `--standard-pascal'
makes GPC behave like other Standard Pascal compilers.)

BTW, there are some other strange things in GPC's interpretation of
field widths:

  * When an Integer value is being output with a field width of zero,
    output is suppressed.  Is this ISO Standard (doesn't seem so),
    or a bug?

  * When a Real value is being output with a too narrow field width,
    other compilers bother to make the output as short as possible.
    Should GPC do the same?

  * All Pascal compilers I have access to have the "feature" that it is
    impossible to output a positive Real value without at least one
    leading blank.  This is annoying in some situations, so what about
    an additional switch, e.g. `--no-real-blank', to disable it
    optionally?  (Better suggestions for the names of all compiler
    switches are welcome!)

That's it for the moment.

Sqr ( BTW ), this switcherism makes it more and more necessary to let
GPC read in a configuration file, or to use `make' to keep all these
switches in a Makefile, or to use RHIDE which provides a menu for them.

Greetings,

    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)