[Oberon] Question about Oberon semantics of VAR parameters

Mon Dec 9 04:40:03 CET 2019

There are two separate concepts here.

1. ARRAY N OF BYTE

2. Extensions of an empty RECORD

They are mutually exclusive. My post that you replied to is only concerned with 1).

Oberon-07 is NOT Component Pascal. They are different for good reason. 

IMHO experimental undocumented features are part of the natural evolution of a living language. The features that prove themselves over a period of time eventually become part of the language definition - the others just fade away into obscurity. Some are just added for convenience to satisfy peculiar requirements of a particular application (in this case Project Oberon).

There are several more in the Project Oberon compiler. I won't mention the others for fear of alarming you further. If they haven't been of any concern to you yet then there's no need to worry about them now.

Regards,
Chris

Chris Burrows
CFB Software
http://www.astrobe.com

> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
> Skulski, Wojciech
> Sent: Monday, 9 December 2019 12:13 PM
> To: ETH Oberon and related systems
> Subject: Re: [Oberon] Question about Oberon semantics of VAR
> parameters
> 
> IMHO this "undocumented Project Oberon compiler extension" is bad.
> First, because it is undocumented. Second, it is non obvious and
> obscure. In BlackBox it was much more clear I think. Should we not
> petition the Almighty to do it the BlackBox way? He was one of the
> directors of that project.
> 
> The following is from the Component Pascal language report. As you
> can see, "ANYREC" is relevant in this context, it is documented, and
> it appearance in the code will make the intention clear.
> 
> Component Pascal Report:
> 
> The predeclared type ANYPTR is defined as POINTER TO ANYREC. Any
> pointer to a record type is therefore an extension of ANYPTR. The
> procedure NEW cannot be used for variables of type ANYPTR.
> 
> Each record is implicitly an extension of the predeclared type
> ANYREC. ANYREC does not contain any fields and can only be used in
> pointer and variable parameter declarations.
> 
> Wojtek
> ________________________________________
> From: Oberon [oberon-bounces at lists.inf.ethz.ch] on behalf of Chris
> Burrows [chris at cfbsoftware.com]
> Sent: Saturday, December 7, 2019 5:03 AM
> To: 'ETH Oberon and related systems'
> Subject: Re: [Oberon] Fwd: Re: Re: Question about Oberon semantics of
> VAR     parameters
> 
> Hi,
> 
> There is a subtle difference between the old rule and the new
> undocumented Project Oberon compiler extension. In the old rule ARRAY
> OF SYSTEM.BYTE matched ANY data type. In the new extension, the
> actual parameter must have the same number of bytes as the formal
> parameter.
> 
> Regards,
> Chris Burrows
> 
> CFB Software
> 
> 
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of J
> rg
> Sent: Saturday, 7 December 2019 7:10 PM
> To: ETH Oberon and related systems
> Subject: Re: [Oberon] Fwd: Re: Re: Question about Oberon semantics of
> VAR parameters
> 
> Hi
> 
> A little bit of history:
> In the previous language report, chapter 12 explained that rule
> https://inf.ethz.ch/personal/wirth/Oberon/Oberon.Report.pdf
> You had to use SYSTEM.BYTE to enable it.
> SYSTEM.BYTE disappeared, but the (now undocumented) rule is still
> there.
> 
> Br
> J rg
> 
> 
> Am 07.12.2019 um 09:32 schrieb J rg
> <joerg.straube at iaeth.ch<mailto:joerg.straube at iaeth.ch>>:
> ?In procedure ORP.Parameter() you find:
> 
> 
> ELSIF (par.type.form = ORB.Array) & (par.type.base = ORB.byteType) &
> (par.type.len >= 0) & (par.type.size = x.type.size) THEN
> 
> J rg
> 
> 
> Am 07.12.2019 um 09:21 schrieb J rg
> <joerg.straube at iaeth.ch<mailto:joerg.straube at iaeth.ch>>:
> ?ARRAY N OF BYTE is compatible to anything as long as the size
> matches.
> This comes in handy for low level programming.
> J rg
> 
> 
> Am 07.12.2019 um 08:51 schrieb Luca Boasso
> <luke.boasso at gmail.com<mailto:luke.boasso at gmail.com>>:
> ?
> To the best of my knowledge, that undocumented feature is the only
> (intentionally) missing type rule in my document.
> The type system described is a slight superset of the one implement
> by the original Oberon-07 RISC compiler.
> Let me know if you need clarifications on the document.
> 
> oberonc implements all the rules of that document. You can find
> comments in the source code referring to the type rules, for example
> in https://github.com/lboasso/oberonc/blob/master/src/OJP.Mod at line
> 216:
> 
>   (* Type Rule A, B *)
> 
>   PROCEDURE EqualTypes(t0, t1: OJB.Type): BOOLEAN;
> 
>   BEGIN
> 
> 
> On Fri, Dec 6, 2019, 19:05 rochus.keller at bluewin.ch wrote:
> Ok, I see, thank you very much.
> 
>  It should be officially documented in any case. I'm implementing my
> first true Oberon validator by just following the language report
> word by word and got tons of inexplicable errors because of rule
> simply not describe there (neither in the tutorial). If I want to be
> able to successfully parse the Oberon System (which seems like an
> obligatory test case) then I consequently have to implement these
> specialities as well. I'm not very good at reading Oberon source code
> (yet) though, so I would prefer a precise and complete language
> report. Your document is already more precise, as it seems.
> 
> Best
> R.
> 
> _______________________________
> From: Luca Boasso
> Sent on: Sat, 07 Dec 2019 03:02:01 +0100
> To: rochus.keller at bluewin.ch<mailto:rochus.keller at bluewin.ch>
> Cc:
> Subject: Re: [Oberon] Fwd: Re: Re: Question about Oberon semantics of
> VAR parameters
> 
> Those particular examples exploit an undocumented loophole in the
> type system that simplify the writing of lower lever functions. I
> left that out of my document.
> 
> 
> See ORP.Parameter:
> ELSIF (par.type.form = ORB.Array) & (par.type.base = ORB.byteType) &
>           (par.type.len >= 0) & (par.type.size = x.type.size) THEN
>         ORG.VarParam(x, par.type)
> 
> 
> 
> 
> On Fri, Dec 6, 2019, 17:45
> rochus.keller at bluewin.ch<mailto:rochus.keller at bluewin.ch>
> <rochus.keller at bluewin.ch<mailto:rochus.keller at bluewin.ch>> wrote:
> 
> This is a very helpful document indeed, thank you very much.
> 
> But as it seems it doesn't explain my originally intended examples,
> e.g FileDir.Mod line 61 or Files.Mod line 104 (the first reported one
> was unfortunately my mishap, sorry).
> 
> Best
> R.
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> systems https://lists.inf.ethz.ch/mailman/listinfo/oberon