According to Phil Nelson:
Thanks MUCH for all your work on gpc. You have greatly improved the compiler!!
Thank you! :-) My next goal are Schema types ...
But I am sure that there are still bugs in the new features, especially in the import mechanism.
I do have a couple of questions about the most recent alpha.
- 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.
In case you have some arguments to set it back to the previous state, just post it here. (These are only some constants in `rts/rts.h', so it was not much work to change. Perhaps (yet another) command-line switch would satisfy everybody?)
- `For' now accepts components of structured variables as control variables, e.g. "for myarray [ i ]:= 1 to 100 do ...".
Why?
In short: Why not?
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?
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 - http://home.pages.de/~gnu-pascal/ [970125]
- 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.
-
Peter Gerwinski -
Phil Nelson