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

[Andreas Pirklbauer]

> 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