<div dir="auto"><div>Hi Andreas,</div><div dir="auto"><br></div><div dir="auto">Thanks for giving that a try!</div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Do you have a comprehensive test suite I could try with oberonc to see if both compilers agree on the result?</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Luca<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Sat, Jul 16, 2022, 09:52 Andreas Pirklbauer <<a href="mailto:andreas_pirklbauer@yahoo.com">andreas_pirklbauer@yahoo.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Luca Boasso luke.boasso at <a href="http://gmail.com" rel="noreferrer noreferrer" target="_blank">gmail.com</a>  Sun May 16 03:13:24 CEST 2021<br>
><br>
> I have two problems in forcing the programmer to think about import ordering: <br>
><br>
> 1. It does not scale. If you have big systems it is hard to hold in your<br>
> head all the import relationships. It is better to have the compiler figure<br>
> it out for you and do the proper checks.<br>
><br>
> 2. It breaks encapsulation. If I (module B) import a module A, I should<br>
> only care about its public interface, not how it is implemented. So if the<br>
> module A re-imports types and indirectly could mess with the import<br>
> order of my module B, we have implementation details leaking through. <br>
> So when the implementation changes the import order of the client<br>
> modules could break.<br>
<br>
Luca,<br>
<br>
I now couldn’t resist and have actually implemented a variant<br>
of ORB that removes the “invalid import order” restriction and<br>
allows hidden re-imports to peacefully coexist with identifiers.<br>
<br>
It was surprisingly straight-forward to implement, only about<br>
15-20 lines of code. Details are here (variant 2):<br>
<br>
<a href="https://github.com/andreaspirklbauer/Oberon-module-imports" rel="noreferrer noreferrer" target="_blank">https://github.com/andreaspirklbauer/Oberon-module-imports</a><br>
<br>
The key idea is to simply propagate reference numbers of<br>
re-exported types from the original module throughout the<br>
module hierarchy (I just add to the information that is<br>
already output for re-exported types). When later a<br>
type T is imported explicitly, one only needs to check<br>
that particular reference number had previously been<br>
re-imported. And if so, the type is discarded after<br>
having read it from the symbol file.<br>
<br>
PS: This would make a nice exercise for a compiler course.<br>
Not much to code, but some thinking is required for sure.<br>
<br>
Andreas<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" target="_blank" rel="noreferrer">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems<br>
<a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</blockquote></div></div></div>