On Mon, 22 Apr 2024 at 00:24, Fischlin Andreas wrote:
In M2 assignments such as
x := y;
or
y := x;
with
VAR x: CARDINAL; y: INTEGER;
have always been legal. Not only in Pascal, but also in Modula-2. The only additional effort needed by a compiler is to generate code that checks for range errors at run time as INTEGER and CARDINAL typically overlap only by the upper (positive) half of INTEGER.
BTW, I took out my old Classic Mac and tested with MacMETH, one of the best PIM compilers, which was first largely written by Niklaus Wirth himself. Compile and run-time errors are encountered exactly for the cases as described in my previous e-mail.
I do not see that here would be any type promotion necessary.
What you described there is type promotion, or as Wirth called it, type inclusion.
I have an email from Wirth from several years ago in which he described this as one of the things "that turned out to be a very bad idea" and as a consequence "corrected this in the latest version of Oberon".
The trouble with Wirth's "Programming in Modula-2" is that the language report contained therein leaves a lot of things unspecified. I am not sure what the ISO standard and its formal semantics definitions say, but Modula-2 is universally described and accepted as following name equivalence.
Name equivalence comes in two variants: loose and strict.
Generally, with name equivalence any two types that have different names are not compatible. With loose name equivalence, types defined as derivatives of others are compatible, with strict name equivalence they are not.
TYPE Celsius = REAL; Fahrenheit = REAL;
Under loose name equivalence Celsius, Fahrenheit and REAL are all compatible with each other.
Under strict name equivalence Celsius, Fahrenheit and REAL are all incompatible with each other.
PIM and ISO Modula-2 follow loose name equivalence.
Therefore, types INTEGER and CARDINAL are not equivalent and entities thereof *should* not be compatible.
Type conversions should be used.
VAR i : INTEGER; n : CARDINAL;
i := VAL(INTEGER, n);
n := VAL(CARDINAL, i);
A compiler needs to generate runtime code to check the values upon conversion, which could then indeed lead to a runtime error when there is no conversion equivalent for the value in the target type's value range.
This is what name equivalence means.
I do not doubt that there are compilers, even written by WIrth himself that don't consequently follow name equivalence, but they should have and Wirth definitely changed his mind on this away from type promotion/type inclusion semantics.
There are other things not clearly specified in the PIM language report such as the semantics of the unary minus which Wirth implemented in an EBNF deduced manner and most compiler implementors followed suit, but some compiler implementors chose to implement mathematically correct (MOCKA and ACK).
A language should be defined by a written specification, not by any implementation.
Clearly, if an implementation goes against mathematical rules, it cannot be considered correct simply because Wirth implemented it that way. If any of Wirth's compilers had implemented 1+1=3, we wouldn't consider that correct either.
I therefore postulate that the mathematically correct interpretation is the only correct way to implement the unary minus and all other compilers, including Wirth's compilers simply have this wrong.
If exceptions to first principle rules are desired, a specification should explicitly name them. For example
"Modula-2 follows loose name equivalence, except for assignments between (1) INTEGER and CARDINAL, (2) INTEGER and LONGINT, (3) LONGINT and CARDINAL, (4) REAL and LONGREAL, where implicit type conversion shall occur."
Absent such explicit exceptions in the specification, any such exceptions in a compiler *should* be regarded as wrong.
regards
benjamin
smime.p7s