[Oberon] Type compatibility in Oberon

[Chris Burrows]

I didn't say it should. You would need to know what range of values INTEGER could assume and how values outside of that range would be handled. 

> -----Original Message-----
> From: Joerg [mailto:joerg.straube at iaeth.ch]
> Sent: Friday, 1 May 2020 11:11 PM
> To: chris at cfbsoftware.com; ETH Oberon and related systems
> Subject: Re: [Oberon] Type compatibility in Oberon
> 
> wrong answer??
> I can not be left to the compiler to decide whether the semantic of a
> decimal literal and a hex literal differ or not.
> 
> J rg
> 
> > Am 01.05.2020 um 15:34 schrieb Chris Burrows <chris at cfbsoftware.com>:
> >
> > ?Check with your supplier's compiler documentation to see what range of
> values are allowed. If it is not specified contact their technical
> support.
> >
> >> -----Original Message-----
> >> From: Joerg [mailto:joerg.straube at iaeth.ch]
> >> Sent: Friday, 1 May 2020 10:39 PM
> >> To: chris at cfbsoftware.com; ETH Oberon and related systems
> >> Subject: Re: [Oberon] Type compatibility in Oberon
> >>
> >> 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
> >
> > --
> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> > systems https://lists.inf.ethz.ch/mailman/listinfo/oberon