[Oberon] Module aliases - what is the correct way to handle them

Luca Boasso luke.boasso at gmail.com
Sun Feb 16 22:20:07 CET 2020


I posted the link of oberonc before in this mailing list:
https://github.com/lboasso/oberonc

It is a compiler for the Java virtual machine that follows the latest
oberon07 report. I keep regularly it up to date. The type system relaxes
some limitations of Prof. Wirth FPGA Oberon, the type rules can be found
here: https://github.com/lboasso/oberonc/blob/master/doc/TypeRules.md


On Sun, Feb 16, 2020, 12:55 PM Joerg <joerg.straube at iaeth.ch> wrote:

> Luca
>
> The out-of-the-box NW compiler does not. What compiler do you use?
> If it‘s your compiler then at least we have one that supports our
> discussed ideas😊
>
> Gruss
> Jörg
>
> Am 16.02.2020 um 21:00 schrieb Luca Boasso <luke.boasso at gmail.com>:
>
> 
> oberonc <https://github.com/lboasso/oberonc> implements the module
> systems based on the ideas of  "On the Linearization of Graphs and
> Writing Symbol Files (1991)"
> <http://e-collection.library.ethz.ch/eserv/eth%3A3310/eth-3310-01.pdf>
>
> The following example compiles and run:
>
> MODULE M0;
>   TYPE T0* = RECORD i: INTEGER END ;
> END M0.
>
> MODULE M7;
>   IMPORT Y := M0, M0, X := M0,
>          S1 := SYSTEM, S2 := SYSTEM;
>   VAR a: Y.T0;
>       b: M0.T0;
>       c: X.T0;
>       i: INTEGER;
> BEGIN
>   a := b;
>   c := a;
>   i := S1.VAL(INTEGER, {1});
>   i := S2.VAL(INTEGER, {2})
> END M7.
>
>
> On Sun, Feb 16, 2020 at 6:04 AM Joerg <joerg.straube at iaeth.ch> wrote:
>
>> thinking of it, the importscope idea is like a generalization of SYSTEM.
>> 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.
>>
>> Currently you can compile
>>
>> IMPORT S1 := SYSTEM, S2 := SYSTEM;
>>
>> this is because SYSTEM lives in an own scope with name „system“.
>>
>> 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.
>>
>> Let me see, how I find time to implement this idea...
>>
>> br
>> Jörg
>>
>> > Am 16.02.2020 um 13:37 schrieb Joerg <joerg.straube at iaeth.ch>:
>> >
>> > Chris
>> >
>> > you‘re absolutely right the aliases must not be allowed on the
>> righthand side.
>> >
>> > 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
>> > Jörg
>> >
>> >> Am 16.02.2020 um 13:16 schrieb Chris Burrows <chris at cfbsoftware.com>:
>> >>
>> >> 
>> >>>
>> >>> -----Original Message-----
>> >>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
>> >>> Paul Reed
>> >>> Sent: Sunday, 16 February 2020 10:38 PM
>> >>> To: ETH Oberon and related systems
>> >>> Subject: Re: [Oberon] Module aliases - what is the correct way to
>> >>> handle them
>> >>>
>> >>> Hi Chris,
>> >>>
>> >>>> I think that the language spec does have such a restriction. In one
>> >>> M0
>> >>>> is a module alias, in the other M0 is an actual module name. A
>> >>> single
>> >>>> identifier (i.e. M0) can't be used for two different purposes in
>> >>> the
>> >>>> same scope... the report says nothing about the order in which the
>> >>>> import list should be processed.
>> >>>> IMPORT Z := M0, M0 := M1 ... Should be treated identically to
>> >>> IMPORT
>> >>>> M0 := M1, Z := M0
>> >>>
>> >>> Thanks, and (I'm sorry if this is boring for everyone else) now I'm
>> >>> beginning to see that Jorg and I are thinking one way and you and
>> >>> Andreas are perhaps thinking another, which has helped me understand
>> >>> where the complications have come in.
>> >>>
>> >>> I don't have a problem with the above being switched around because I
>> >>> (and Jorg) see the aliases and the canonical module names as
>> >>> different things.  I think you and Andreas are allowing a module
>> >>> alias to appear on the right hand side of an alias definition, but I
>> >>> wouldn't.  What's right?
>> >>>
>> >>
>> >> No - I agree with you. I was just pointing out that if aliases were
>> allowed
>> >> on the right hand side of an alias definition it could result in
>> ambiguous
>> >> import lists.
>> >>
>> >> --
>> >> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
>> systems
>> >> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>> >
>> > --
>> > Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
>> systems
>> > https://lists.inf.ethz.ch/mailman/listinfo/oberon
>>
>> --
>> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
>> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
> --
> 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/20200216/379f797e/attachment.html>


More information about the Oberon mailing list