Nor should they be compatible, because Modula-2 follows name equivalence.
Under name equivalence, any two types with different names are in principle incompatible.
However, there are two types of name equivalence. Loose and strict name equivalence.
Under loose name equivalence any two types are compatible if one is an accidental alias of the other. Accidental alias means there is no way to determine whether declaring an alias type was indeed intentional.
Under strict name equivalence accidental alias types are incompatible. In languages that follow strict name equivalence, there is usually a separate syntax form to declare an intentional alias type. One syntax form to declare a derivative type, which is then incompatible with the type it is based on, and another syntax form to declare an intentional alias type, which is then compatible with the type of which it is an alias.
PIM and ISO Modula-2 follow loose name equivalence.
TYPE Celsius = REAL;
TYPE Fahrenheit = REAL;
=> types Celsius, Fahrenheit and REAL are all compatible.
Was it intentional to make Celsius and Fahrenheit compatible? Probably not. But PIM and ISO Modula-2 do not provide any syntax to distinguish between the declaration of a derived type and an alias type. Hence, loose name equivalence.
Ada and Modula-2 R10 follow strict name equivalence.
in Ada:
type celsius = new real;
type fahrenheit = new real;
=> types celsius and fahrenheit are derived types and thus all are incompatible.
=> type int is an intentional alias of type integer, therefore both are compatible.
in M2R10:
TYPE Celsius = REAL;
TYPE Fahrenheit = REAL;
=> types Celsius and Fahrenheit are derived types and thus all are incompatible.
TYPE INT = ALIAS OF INTEGER;
=> type INT is an intentional alias of type INTEGER, therefore both are compatible.
In GM2, the type on which INTEGER is based depends on the target platform and/or memory model. Under some circumstances, INTEGER may well be based on INTEGER32, but under other circumstances it is not.
This means, if INTEGER was to be made compatible with INTEGER32, this would need to apply only under those circumstances where INTEGER is actually based on INTEGER32, but not under any other circumstances. However, this would break the code when it is compiled for a different target or memory model where INTEGER is not based on INTEGER32.
Therefore, the two should not be compatible.
Of course that doesn't mean that integer literals cannot be compatible with both types.
VAR i : INTEGER; i32 : INTEGER32;
i := -1234;
i32 := -1234;
but certainly not
i := i32;
nor
i32 := i;
For these assignments, the VAL function should be used to convert the value to the target type
i := VAL(INTEGER, i32);
i32 := VAL(INTEGER32, i);
hope this clarifies.
regards
benjamin