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

[Luca Boasso]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20200216/128a5804/attachment-0001.html>