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

[Joerg]

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 implements the module systems based on the ideas of  "On the Linearization of Graphs and Writing Symbol Files (1991)"
> 
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200216/e083f751/attachment.html>