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.
It's actually in the manual (Programming / Library Routines / String Operations)....
Indeed, so it is. I missed that.
BTW, that "--gnu-pascal" implies this option can be seen in gpc-options.h.
Thanks for pointing that out. Quite useful to know, actually.
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 expect GP mode to give me an enhanced version of Pascal, so allowing undefined case values, e.g., would not be surprising. What is surprising is finding that the program that worked when compiled in EP mode now fails with the same inputs in GP mode.
This is also not actually EP-incompatible, just different from a "typical" behaviour of other EP compilers.... [...] So if you want to write portable EP code, you cannot rely on any default width anyway.
Quite right, and I doubt many production programs use the default field widths. I generally use them, though, for debugging outputs. And while changing the default width to one doesn't stop a valid EP program from working, it is a bit confusing. My debug statement:
writeln ('file position/index are ', position (datafile), counter);
began to produce, in GP mode:
file position/index are 125365
instead of the EP mode:
file position/index are 1253 65
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.
If all of the mode changes are made through 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.
-- Dave