[Oberon] Question about Oberon semantics of VAR parameters

[Skulski, Wojciech]

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.