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

[Luca Boasso]

Thanks, I'll go over the links!

On Sat, Jul 16, 2022, 15:54 Andreas Pirklbauer <andreas_pirklbauer at yahoo.com>
wrote:

> 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
>
> --
> 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/20220716/64fd6c5c/attachment.html>