<div dir="auto">I posted the link of oberonc before in this mailing list: <a href="https://github.com/lboasso/oberonc">https://github.com/lboasso/oberonc</a><div dir="auto"><br></div><div dir="auto">It is a compiler for the Java virtual machine that follows the latest oberon07 report. I keep <font face="sans-serif">regularly</font> it up to date. The type system relaxes some limitations of Prof. Wirth FPGA Oberon, the type rules can be found here: <a href="https://github.com/lboasso/oberonc/blob/master/doc/TypeRules.md">https://github.com/lboasso/oberonc/blob/master/doc/TypeRules.md</a></div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 16, 2020, 12:55 PM Joerg <<a href="mailto:joerg.straube@iaeth.ch" target="_blank" rel="noreferrer">joerg.straube@iaeth.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Luca<div><br><div><span style="color:rgb(0,0,0)">The out-of-the-box NW compiler does not. </span>What compiler do you use?</div><div>If it‘s your compiler then at least we have one that supports our discussed ideas😊</div><div><br><div dir="ltr">Gruss<div>Jörg</div></div><div dir="ltr"><br><blockquote type="cite">Am 16.02.2020 um 21:00 schrieb Luca Boasso <<a href="mailto:luke.boasso@gmail.com" rel="noreferrer noreferrer" target="_blank">luke.boasso@gmail.com</a>>:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><a href="https://github.com/lboasso/oberonc" rel="noreferrer noreferrer" target="_blank">oberonc</a> implements the module systems based on the ideas of<a href="http://e-collection.library.ethz.ch/eserv/eth%3A3310/eth-3310-01.pdf" rel="noreferrer noreferrer" target="_blank"> "On the Linearization of Graphs and Writing Symbol Files (1991)"</a></div><div><br></div><div>The following example compiles and run:</div><div><pre style="background-color:rgb(255,255,255);color:rgb(0,0,0);font-family:"DejaVu Sans Mono";font-size:9.8pt">MODULE M0;<br> TYPE T0* = RECORD i: INTEGER END ;<br>END M0.</pre></div><div><pre style="background-color:rgb(255,255,255);color:rgb(0,0,0);font-family:"DejaVu Sans Mono";font-size:9.8pt">MODULE M7;<br> IMPORT Y := M0, M0, X := M0,<br> S1 := SYSTEM, S2 := SYSTEM;<br> VAR a: Y.T0;<br> b: M0.T0;<br> c: X.T0;<br> i: INTEGER;<br>BEGIN<br> a := b;<br> c := a;<br> i := S1.VAL(INTEGER, {1});<br> i := S2.VAL(INTEGER, {2})<br>END M7.</pre></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Feb 16, 2020 at 6:04 AM Joerg <<a href="mailto:joerg.straube@iaeth.ch" rel="noreferrer noreferrer" target="_blank">joerg.straube@iaeth.ch</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">thinking of it, the importscope idea is like a generalization of SYSTEM.<br>
Currently, ORB has a special invisible scope for the module SYSTEM. And it has a special treatment like IF modid1 = “SYSTEM“ THEN it links those objects to topscope.<br>
<br>
Currently you can compile<br>
<br>
IMPORT S1 := SYSTEM, S2 := SYSTEM;<br>
<br>
this is because SYSTEM lives in an own scope with name „system“.<br>
<br>
The generalization of it would be that all imported modules (including SYSTEM) are imported into importscope and the special treatment IF modid1=“SYSTEM“ is replaced with a search in importscope.<br>
<br>
Let me see, how I find time to implement this idea...<br>
<br>
br<br>
Jörg<br>
<br>
> Am 16.02.2020 um 13:37 schrieb Joerg <<a href="mailto:joerg.straube@iaeth.ch" rel="noreferrer noreferrer" target="_blank">joerg.straube@iaeth.ch</a>>:<br>
> <br>
> Chris<br>
> <br>
> you‘re absolutely right the aliases must not be allowed on the righthand side.<br>
> <br>
> If I think of a possible implementation, the righthand sides and lefthand sides might live in different scopes, eg lefthand side are objects visible in the well known topscope, the righthand sides (aka filenames :-) might live in a new importscope... Just thinking loud.<br>
> <br>
> br<br>
> Jörg<br>
> <br>
>> Am 16.02.2020 um 13:16 schrieb Chris Burrows <<a href="mailto:chris@cfbsoftware.com" rel="noreferrer noreferrer" target="_blank">chris@cfbsoftware.com</a>>:<br>
>> <br>
>> <br>
>>> <br>
>>> -----Original Message-----<br>
>>> From: Oberon [mailto:<a href="mailto:oberon-bounces@lists.inf.ethz.ch" rel="noreferrer noreferrer" target="_blank">oberon-bounces@lists.inf.ethz.ch</a>] On Behalf Of<br>
>>> Paul Reed<br>
>>> Sent: Sunday, 16 February 2020 10:38 PM<br>
>>> To: ETH Oberon and related systems<br>
>>> Subject: Re: [Oberon] Module aliases - what is the correct way to<br>
>>> handle them<br>
>>> <br>
>>> Hi Chris,<br>
>>> <br>
>>>> I think that the language spec does have such a restriction. In one<br>
>>> M0<br>
>>>> is a module alias, in the other M0 is an actual module name. A<br>
>>> single<br>
>>>> identifier (i.e. M0) can't be used for two different purposes in<br>
>>> the<br>
>>>> same scope... the report says nothing about the order in which the<br>
>>>> import list should be processed.<br>
>>>> IMPORT Z := M0, M0 := M1 ... Should be treated identically to<br>
>>> IMPORT<br>
>>>> M0 := M1, Z := M0<br>
>>> <br>
>>> Thanks, and (I'm sorry if this is boring for everyone else) now I'm<br>
>>> beginning to see that Jorg and I are thinking one way and you and<br>
>>> Andreas are perhaps thinking another, which has helped me understand<br>
>>> where the complications have come in.<br>
>>> <br>
>>> I don't have a problem with the above being switched around because I<br>
>>> (and Jorg) see the aliases and the canonical module names as<br>
>>> different things. I think you and Andreas are allowing a module<br>
>>> alias to appear on the right hand side of an alias definition, but I<br>
>>> wouldn't. What's right?<br>
>>> <br>
>> <br>
>> No - I agree with you. I was just pointing out that if aliases were allowed<br>
>> on the right hand side of an alias definition it could result in ambiguous<br>
>> import lists.<br>
>> <br>
>> --<br>
>> <a href="mailto:Oberon@lists.inf.ethz.ch" rel="noreferrer noreferrer" target="_blank">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 noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
> <br>
> --<br>
> <a href="mailto:Oberon@lists.inf.ethz.ch" rel="noreferrer noreferrer" target="_blank">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 noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
<br>
--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" rel="noreferrer noreferrer" target="_blank">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 noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</blockquote></div>
<span>--</span><br><span><a href="mailto:Oberon@lists.inf.ethz.ch" rel="noreferrer noreferrer" target="_blank">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems</span><br><span><a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon" rel="noreferrer noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a></span><br></div></blockquote></div></div></div>--<br>
<a href="mailto:Oberon@lists.inf.ethz.ch" rel="noreferrer noreferrer" target="_blank">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 noreferrer" target="_blank">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a><br>
</blockquote></div>