[Oberon] Type compatibility in Oberon

[Joerg]

Is using 90909090H an undefined feature?
What value does it represent?

br
Jörg

> Am 01.05.2020 um 14:13 schrieb Chris Burrows <chris at cfbsoftware.com>:
> 
> Not exactly. This amended statement is more accurate:
> 
> "It is not guaranteed that a program THAT USES UNDEFINED FEATURES compiled
> with two different implementations of the same report behave in the same
> way."
> 
> I find that neither surprising nor anything to be concerned about. I
> sincerely hope that an Oberon programmer would not assume otherwise.
> 
> Regards,
> Chris Burrows
> CFB Software
> https://www.astrobe.com
> 
>> -----Original Message-----
>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
>> Andreas Pirklbauer
>> Sent: Friday, 1 May 2020 6:36 PM
>> To: Oberon List
>> Subject: [Oberon] Type compatibility in Oberon
>> 
>>> Oberon as it is defined in the report leaves some parts needed for
>> low level programming to the implementation.
>> 
>> At the heart the problem appears to be two-fold: a) the language leaves
>> certain things undefined, and b) in order to truly implement an entire
>> system like the Oberon system, one has to cheat (at least a little). For
>> example, today it is not guaranteed that a program compiled with two
>> different implementations of the same report behave in the same way.
>> 
>> 
>> 
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon