Defining Distinct Numeric Types

[August Karlstrom]

Hi,

Does anyone know if there is a way to introduce distinct numeric types
in Oberon? At least with the OOC compiler, the module below compiles.

MODULE Test;
TYPE T1 = INTEGER; T2 = INTEGER;
VAR v1: T1; v2: T2;
BEGIN
v1 := 1; v2 := v1;
END Test.

I would "like" the last statement to be invalid.


Regards,

August

[Andreas F. Borchert]

Post by August Karlstrom
Does anyone know if there is a way to introduce distinct numeric types
in Oberon? At least with the OOC compiler, the module below compiles.
MODULE Test;
TYPE T1 = INTEGER; T2 = INTEGER;
VAR v1: T1; v2: T2;
BEGIN
v1 := 1; v2 := v1;
END Test.
I would "like" the last statement to be invalid.

This is not possible in Oberon. T1 and T2 are considered identical
despite the two distinct type declarations because both are related to
INTEGER. You do not have structural equivalence, though. Example:

MODULE Test;
TYPE T1 = RECORD i: INTEGER END; T2 = RECORD i: INTEGER END;
VAR v1: T1; v2: T2;
BEGIN
v1.i := 1;
v2 := v1; (* is not accepted by the compiler *)
END Test.

This is also in conformance to the compatibility rules of
Modula-2. Modula-3, a derivative of Modula-2 that was developed at DEC,
supported ``branded'' data types which enforced a distinction where
otherwise types would have been considered identical.

Andreas.

[August Karlstrom]

Post by Andreas F. Borchert

Post by August Karlstrom
Does anyone know if there is a way to introduce distinct numeric types
in Oberon? At least with the OOC compiler, the module below compiles.
MODULE Test;
TYPE T1 = INTEGER; T2 = INTEGER;
VAR v1: T1; v2: T2;
BEGIN
v1 := 1; v2 := v1;
END Test.
I would "like" the last statement to be invalid.

This is not possible in Oberon. T1 and T2 are considered identical
despite the two distinct type declarations because both are related to
MODULE Test;
TYPE T1 = RECORD i: INTEGER END; T2 = RECORD i: INTEGER END;
VAR v1: T1; v2: T2;
BEGIN
v1.i := 1;
v2 := v1; (* is not accepted by the compiler *)
END Test.
This is also in conformance to the compatibility rules of
Modula-2. Modula-3, a derivative of Modula-2 that was developed at DEC,
supported ``branded'' data types which enforced a distinction where
otherwise types would have been considered identical.

OK, thanks for the input. Still though, I wonder about the motivation
for the decision. If I introduce different types, I want them to be
different.


August

[Ludovic Brenta]

Post by August Karlstrom
OK, thanks for the input. Still though, I wonder about the motivation
for the decision. If I introduce different types, I want them to be
different.

I agree with you. That's why I use Ada :)