[Oberon] Type compatibility in Oberon

[Chris Burrows]

Thank you for the reference. However, I could not see anything there that stated that extensions to the language extensions had been included. An immediate problem that jumps out at me is rule G4:

 

f is a parameter of type ARRAY m OF BYTE and Ta is any type with size n = m bytes.

 

That rule is *not* part of the latest 2016 version of Oberon language definition (or any previous version AFAIR). You may have been misled by the fact that It is an undocumented feature that has been implemented in the RISC5 Oberon compiler. As I have stated here recently the RISC5 compiler should not be treated as if it were a language reference compiler.

 

Regards,

Chris Burrows

CFB Software

https://www.astrobe.com

 

From: Luca Boasso [mailto:luke.boasso at gmail.com] 
Sent: Friday, 1 May 2020 3:37 PM
To: chris at cfbsoftware.com; ETH Oberon and related systems
Subject: Re: [Oberon] Type compatibility in Oberon

 

For an up to date and comprehensive list of type rules for Oberon-07 you can also refer to:  https://github.com/lboasso/oberonc/blob/master/doc/TypeRules.md

oberonc slightly generalizes the implied rules in Prof. Wirth latest source code.

 

Comments like "(* Type Rule F.1, F.2 *) <https://github.com/lboasso/oberonc/blob/master/src/OJP.Mod#L230> " clearly link the definition in the document with the actual implementation in the code, leaving little space for interpretation.

 

 

On Thu, Apr 30, 2020, 15:32 Chris Burrows <chris at cfbsoftware.com <mailto:chris at cfbsoftware.com> > wrote:

When I followed the link in the post below the item that really grabbed my
attention was the excellent document:

Type compatibility in Oberon

https://www.miasap.se/obnc/type-compatibility.html

It is apparent to me that a lot of thought has gone into the preparation of
this document. It would be very useful to any Oberon programmer who was
having difficulty understanding why his program would not compile due to a
type-compatibility issue.

I haven't used OBNC so can't say how well it conforms to these rules -
knowing August's great attention to detail I would expect it to be 'very
well'. While the Astrobe ARM compilers comply with the vast majority of
these rules there are one or two minor exceptions. These are described in
the accompanying documentation. You should also expect some very minor
relaxations of the rules (e.g. ARRAY OF BYTE parameters) when using the
Project Oberon RISC5 compiler. 

Regards,
Chris Burrows
CFB Software
https://www.astrobe.com



> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch <mailto:oberon-bounces at lists.inf.ethz.ch> ] On Behalf Of
> August Karlstrom
> Sent: Friday, 1 May 2020 2:00 AM
> To: oberon at lists.inf.ethz.ch <mailto:oberon at lists.inf.ethz.ch> 
> Subject: Re: [Oberon] Interfacing with Foreign Systems
> 
> On 2020-04-30 01:50, Skulski, Wojciech wrote:
> > Chris:
> >
> >    how about OOC and OO2C? Are they not in the same spirit?
> >
> > http://ooc.sourceforge.net/index.html
> 
> OBNC is a better example. It targets the latest version of Oberon and is
> actively maintained.
> 
> https://www.miasap.se/obnc/
> 
> 
> -- August
> --
> Oberon at lists.inf.ethz.ch <mailto: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 <mailto:Oberon at lists.inf.ethz.ch>  mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200501/b852f185/attachment.html>