[Oberon] Should hidden re-imports be able to coexist with identifiers

[Andreas Pirklbauer]

Hi Luca,

See my inline answers below:

  > Luca Boasso luke.boasso at gmail.com Sat Jul 16 20:22:54 CEST 2022
  >
  > Hi Andreas, 
  > 
  > Thanks for giving that a try!
  > 
  > Is this approach over all simpler than the one I am using in oberonc? It is hard for me to say since your solution evolved over time, but you should be able to give your take since you knew about the Griesemer's approach.

Yes, my approach is considerably (!) simpler than oberonc and Griesemer’s approach.. in the sense that I found a way to do away with module anchors and global module tables completely. If on http://github.com/andreaspirklbauer/Oberon-module-imports you scroll down to section 6., the approach is briefly explained (I essentially propagate the reference number of each re-exported type through the module hierarchy and then use that number to detect whether a type has already been re-imported or not).

  > Do you have a comprehensive test suite I could try with oberonc to see if both compilers agree on the result? 

I have now added (essentially your) test suite here: 

    https://github.com/andreaspirklbauer/Oberon-module-imports/tree/master/Sources/TestImport

There is a file called TESTIMPORT.Tool which contains a single ORP.Compile command that compiles the test suite.

All module compile correctly except for 3 cases, which I intentionally disallow (I don’t allow creating more than one alias per imported module or importing the same module twice, finally PO 2013 doesn’t allow external pointer base types - I restriction which I just inherited and didn’t want to touch).

I could easily allow those cases as well, but then I would need to change the symbol table data structure in topScope. This seemed unnecessary.

For further reading on the rationale used and a proof that indeed all possible cases are covered by it, see:

    https://github.com/andreaspirklbauer/Oberon-module-imports/blob/master/Documentation/Allowing-reimports-to-coexist-with-module-aliases-and-identifiers.md

as well as the test file

    https://github.com/andreaspirklbauer/Oberon-module-imports/blob/master/Sources/TestImport/TestImport.Mod

You can just click through the various modules contained in this file. They really cover all possible cases. This is comforting to know.

> Cheers, Luca

Cheers,
Andreas

> > On Sat, Jul 16, 2022, 09:52 Andreas Pirklbauer <andreas_pirklbauer at yahoo.com> wrote: > > Luca Boasso luke.boasso at gmail.com Sun May 16 03:13:24 CEST 2021 
> > 
> > I have two problems in forcing the programmer to think about import 
> ordering: 
> > 
> > 1. It does not scale. If you have big systems it is hard to hold in your 
> > head all the import relationships. It is better to have the compiler 
> figure 
> > it out for you and do the proper checks. 
> > 
> > 2. It breaks encapsulation. If I (module B) import a module A, I should 
> > only care about its public interface, not how it is implemented. So if 
> the 
> > module A re-imports types and indirectly could mess with the import 
> > order of my module B, we have implementation details leaking through. 
> > So when the implementation changes the import order of the client 
> > modules could break. 
>
> Luca, 
>
> I now couldn’t resist and have actually implemented a variant 
> of ORB that removes the “invalid import order” restriction and 
> allows hidden re-imports to peacefully coexist with identifiers. 
>
> It was surprisingly straight-forward to implement, only about 
> 15-20 lines of code. Details are here (variant 2): 
>
> https://github.com/andreaspirklbauer/Oberon-module-imports
>
> The key idea is to simply propagate reference numbers of 
> re-exported types from the original module throughout the 
> module hierarchy (I just add to the information that is 
> already output for re-exported types). When later a 
> type T is imported explicitly, one only needs to check 
> that particular reference number had previously been 
> re-imported. And if so, the type is discarded after 
> having read it from the symbol file. 
>
> PS: This would make a nice exercise for a compiler course. 
> Not much to code, but some thinking is required for sure. 
>
> Andreas