New Alpha_(re)

Wed, 2 Apr 1997 12:12:30 -0800 (PST)

>> >  * Field widths now default to left-justified output.
>> 
>> Did I miss a discussion on this?  Doesn't this break a lot of programs?
>> Or is this with "--borland-pascal"?
>
>Perhaps my formulation was misleading:  I mean that
>
>    writeln ( 123 );
>
>will no more yield the output
>
>    _______123
>
>(with seven blanks), but instead
>
>    123
>
>(left-justified).  To produce "_______123" you must explicitly say
>"writeln ( 123 : 10 );".
>
>The Standard says that these default widths are implementation-dependent.
>There was a short discussion about whether GPC's behavior (default width
>10 for Integers, 14 for Reals, 6 for Booleans) was a good decision.
>We soon agreed that it would be better to produce left-justified output
>when no width has been specified.  Otherwise, you would have to say
>"writeln ( 123 : 1 );" to get the left-justified "123" which is clumsy
>and misleading.  We forgot to post a copy of the discussion to the list;
>sorry about that.

Yes, I understood what you ment.  I'm sorry that the discussion did not
make it to the gpc list.

Let me argue that the orignal method should be maintained, with the actual
numbers being changed to larger values.

First some of my background with Pascal.  I had several discussions with
Ted C. Park during the original work on the Pascal standard.  (Yes, you
will find Ted's name on page iii of the ISO 7185:1990 standard.)  I have
used many Pascal compilers, including Pascal 6000-3.4, Portable Pascal,
VAX Pascal, OMSI Pascal, GNU Pascal and Borland Pascal.  I even modified
the portable Pascal compiler to generate native machine code for the
HP3000.

As to why the implicit field size in a "write(i)" should not be 1:

A) This change breakes a lot of non-Borland Pascal programs.  The point
of a standard is so that programs that work under one compiler work under
other compilers and that includes I/O. 

B) I believe that any "write(a)" with no field specification
where a is a numeric type should produce output that can be read
back with no loss of information.  I believe that it should
the case (although not stated in the standard) that the output from
   write(f1,a,b,c)
should be able to fed to the statment
   read(f2,x,y,z)
and have the read statement correctly assign the values to
x, y, and z that were in a, b and c.  (Should work for integer, real, char.)

Of all the Pascal compilers I have used, only Borland did not guarantee
that the above will work.  (Possibly gpc with LARGE integers :)

C) Notice, the way the standard is written for reals,
write(f1,r1,r2,r3) will write the numbers so that read(f2,r1,r2,r3)
will read the numbers back in.  There may be loss of precision if the
implementation-dependent number is too small, but the write and read
will "communicate".  (That is the first character written is always a
"+" or a blank.)

C) The "implementation-dependent" feature is due to the fact that some
implementations have, for integers, 16 bits of representation and needs
only a field size of 6 to guarantee the write/read usage.  For 32 bits of 
representation we really need 11 to guarantee the write/read.  For 64 bits,
we would need 20.  This is how I see it as implementation-dependent.  (Yes,
if they really ment this, they should have specified it.)

I would have no problem with the implicit field of 1 if it was looking like
a Borland compiler.  Similar with the  "write ('abcdefg':3)" writing
"abcdefg" instead of the proper "abc".  Both of the above (the changes in how
write operates) are reasons I have avoided using Borland Pascal. 

I think that the standard mode for gpc (no special flags) should 
	a) have a default field size that guarantees that the first character
		is either a "+" or a blank when writing numeric types.
		(Defined by the standard for real.  Should have a size large
		enough to not loose very much precision due to write/read.)
	b) write ('abcdefg':3) must write exactly "abc".

I have many Pascal programs that depend on both of the above features.


>> >  * `For' now accepts components of structured variables as control
>> >    variables, e.g. "for myarray [ i ]:= 1 to 100 do ...".
>> 
>> Why?
>
>In short:  Why not?

As you note below, the standard only allows ordinal type, single variables
here.  It also requires the variable to be defined in the closest containing
variable declaration block?  Is that being enforced with array loop indexes?
Also, I think it can be very confusing.  Granted, it does make a few problems
solved with a line or two less code.

>
>In long:  Indeed, the standard only allows an entire variable in this
>context.  Thank you for pointing me to this; I will make this extension
>trigger a warning if `--standard-pascal' or `--extended-pascal' has
>been specified.  (With `--pedantic-errors', the warning will be an
>error message.)  But Borland Pascal allows this, I got it "for free"
>(just changed one line in `gpc-parse.y'), so why not allow it, too?

I believe that it should be enabled only if '--borland-pascal' is requested.
Otherwise it should be rejected.  

I suspect that it would require the modification/addition of only one line
to the gpc-parse.y to allow 'var++' as an expression.  Should we add it?
NO.  I'd like to have gpc avoid the "kitchen sink" syndrome.  

In any case, as you point out, with '--standard-pascal' it had better follow
the standard.

-- 
Phil Nelson                       NetBSD: http://www.netbsd.org
e-mail: phil@cs.wwu.edu           LPF: http://www.lpf.org
http://www.cs.wwu.edu/~phil       !gifs: http://www.lpf.org/Patent/Gif/Gif.html

Phil Nelson (phil@cs.wwu.edu)