J. David Bryan wrote:
On 6 Aug 2006 at 1:37, Frank Heckenbach wrote:
I guess I spent at least as long when confronted with the EP behaviour (very surprising and unintuitive to me) for the first time ...
I learned Pascal on several HP computer systems, and all of them had the extension that unequal-length strings were blank-padded for comparisons. So EP seems quite normal to me.
I think it only makes sense for backward-compatibility with CP (which didn't have strings with a length field, except hand-made ones, and blank-padding was used instead, which I'd call a kludge already). When you often parse input lines or construct output lines from strings and want to control the spacing yourself instead of relying on default widths, trailing spaces make quite a difference. Anyway.
These are the ones I see:
[...]
I'm less worried about behavior that would be invalid or undefined in EP than about behavior changes that occur when a valid EP program with valid EP input is compiled in GP mode.
I think I mentioned only such.
I expect GP mode to give me an enhanced version of Pascal, so allowing undefined case values, e.g., would not be surprising.
Depends. If the EP program relied on aborting on an unmatched case value as it may validly do in EP since it's a dynamic-violation, not only an error (such an abort may not look to nice, but perhaps acceptable for a batch-style program), GPC's default behaviour would lead to unintended (and perhaps wildly wrong) behaviour.
leading me at first to wonder how the file position got so far out of bounds. :-) Certainly this should not produce a warning in the compiler, but it would be helpful to have the manual detail somewhere the changes that occur when switching modes that might affect a valid program with valid inputs.
OK. So far we have this thread. You might want to start collecting the relevant information, perhaps changing the formulations to fit manual style, and suggest where to insert it in the manual. And if you or someone else finds more such issues, please point them out.
If all of the mode changes are made through option switches,
No, not all. (That would mean adding another couple of dozen option switches ...)-:
then perhaps a table could be put in the "GPC Command Line Options" section, with options in rows and dialects in columns, to show which options are default for which dialects (essentially describing the settings in gpc-options.h). That would be easier, in my view, than trying to decipher the various "default in xxx" statements that now accompany most -- though not all -- of the option descriptions.
From gpc-options.h we could probably generate such a table
automatically with some effort, but as I said, it wouldn't capture all dialect differences ...
Frank