[Oberon] Fwd: Fwd: Fwd: Re: Re: Question about Oberon semantics of VAR parameters

[rochus.keller at bluewin.ch]

Here is another example:
Files.Mod : line 104 col 47
There are many similar ones.

Meanwhile I realized that my first example "v.handle(v, M)" with FrameMsg was bogus, sorry for that. I was obviously too confused by the other examples (which I discovered first). 

Best
R.


----Ursprüngliche Nachricht----
Von : rochus.keller at bluewin.ch
Datum : 07/12/2019 - 01:48 (CET)
An : oberon at lists.inf.ethz.ch
Betreff : Fwd: Fwd: Re: Re: [Oberon] Question about Oberon semantics of VAR parameters

Here is an example:

FileDir.Mod line 61 states "Kernel.GetSector(dadr, a)". GetSector requires an "ARRAY SectorLength OF BYTE" as it's second argument. But "a" is of type 
DirPage*  =
      RECORD mark*:  INTEGER;
        m*:     INTEGER;
        p0*:    DiskAdr;  (*sec no of left descendant in directory*)
        fill:  ARRAY FillerSize OF BYTE;
        e*:  ARRAY DirPgSize OF DirEntry
      END ;

Best
R.
----Ursprüngliche Nachricht----
Von : rochus.keller at bluewin.ch
Datum : 07/12/2019 - 01:28 (CET)
An : oberon at lists.inf.ethz.ch
Betreff : Fwd: Re: Re: [Oberon] Question about Oberon semantics of VAR parameters

Thanks for your response.

> FrameMsg is the base type of ViewerMsg or in other words ViewerMsg is an extension of FrameMsg.
No, it isn't. It's type definition is "FrameMsg = RECORD END;" as mentioned. Only the identifier is the same (whereas in different modules). So an actual type with a completely unrelated type is assigned to the formal type of the VAR parameter. There are many other examples, some where even a record is assigned to a byte array.

Best
R.

----Ursprüngliche Nachricht----
Von : joerg.straube at iaeth.ch
Datum : 07/12/2019 - 01:24 (CET)
An : rochus.keller at bluewin.ch
Betreff : Re: [Oberon] Question about Oberon semantics of VAR parameters
https://inf.ethz.ch/personal/wirth/Oberon/Oberon07.Report.pdf
 Chapter 9.1, bullet 3
 
 
 
  Jörg
 
 
  
  
   Am 07.12.2019 um 01:17 schrieb Jörg <joerg.straube at iaeth.ch>:
   
   
  
 
 
  
   
   FrameMsg is the base type of ViewerMsg or in other words ViewerMsg is an extension of FrameMsg.
   
   
   
   All extensions are assignment compatible to the base type
   
   
   
   Jörg
   
   
   
   
    Am 07.12.2019 um 00:33 schrieb "rochus.keller at bluewin.ch" <rochus.keller at bluewin.ch>:
    
   
   
    
    
   
   
    Can someone please explain to me why the following code in the module display of the Oberon system does not cause a compiler error.
    
   
   
    
    
   
   
    On line 38 there is the statement "v.handle(v, M)" with "handle" being of procedure type "PROCEDURE (F: Frame; VAR M: FrameMsg);" with "FrameMsg = RECORD END;" and the actual parameter M has the following type:
    
   
   
    ViewerMsg* = RECORD (Display.FrameMsg)
    
   
   
           id*: INTEGER;
    
   
   
           X*, Y*, W*, H*: INTEGER;
    
   
   
           state*: INTEGER
    
   
   
         END;
    
   
   
    
    
   
   
    Since FrameMsg and ViewerMsg are not related and the formal and actual parameter M are not the same according to the Oberon-07 language report and "Programming in Oberon" (2004 edition) I would expect an error, but the compiler accepts it. This is just one of many similar examples. Do I completely misinterpret both documents or is the implemented one actually different from the specified language?
    
   
   
    
    
   
   
    Best
    
   
   
    R.
    
   
   
    --
    
   
   
    Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
    
   
   
    https://lists.inf.ethz.ch/mailman/listinfo/oberon