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

[Luca Boasso]

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.

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

Cheers,
Luca

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/222306d0/attachment.html>