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

[Chris Burrows]

When discussing this possible use of module aliases I would ask not so much "How can you do this?", but "Should you even try to do this?" 

If debug output is useful in the lab it is going to be even more useful when your application is out in the field. The majority of tech support problems I've had to handle in the last 20+ years would have been infinitely more difficult if not impossible if I hadn't built debugging trace features into the design of the software itself - not as an afterthought. The more you can limit the differences between 'debug mode' and 'release mode' the better off you will be in the long term. 

Paul Reed has mentioned this principle here in the past. I have managed to track down the actual quote by Prof C.A.R. Hoare:

"For a large and complex program, the extra inefficiency of the debugging runs may be serious; and even on small programs, the cost of loading a large debugging system can be high. You should always pity the programmer whose task is so difficult that his program will not fit into the computer together with your sophisticated debugging package. Finally it is absurd to make elaborate security checks on debugging runs, when no trust is put in the results, and then remove them in production runs, when an erroneous result could be expensive or disastrous. What would we think of a sailing enthusiast who wears his lifejacket when training on dry land, but takes it off as soon as he goes to sea?"

Ref: Hints on Programming Language Design, C.A.R Hoare, Dec 1973

https://dl.acm.org/doi/book/10.5555/892013

Fortunately, any efficiency overheads of the additional debugging code is much less of a problem on the computing systems available today. 

Regards,
Chris

Chris Burrows
CFB Software
https://www.astrobe.com


> -----Original Message-----
> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of Joerg
> Sent: Tuesday, 14 July 2020 8:45 AM
> To: ETH Oberon and related systems
> Subject: Re: [Oberon] Module aliases - what is the correct way to handle
> them
> 
> Sorry, August (mixed up your name??)
> 
> Perhaps this pseudo code makes my point even clearer:
>    IMPORT Out, Debug := Out;
> could be seen as
>    CONST
>       Out = SYSTEM.Import( Out.sym );
>       Debug = SYSTEM.Import( Out.sym );
> 
> br
> J rg
> 
> > Am 14.07.2020 um 00:57 schrieb Joerg <joerg.straube at iaeth.ch>:
> >
> > ?Karl
> >
> > To better vizualize what  import aliasing  should be doing in my point of
> view, I tried to explain it with a kind of pseudo code. It s not valid
> Oberon, only meant to explain the idea:
> >
> >   IMPORT Out;
> > can be seen as a shortcut of the pseudo code
> >   CONST Out = import.Out;
> >
> > Likewise
> >   IMPORT Debug := Out;
> > can be seen as a shortcut of
> >   CONST Debug = import.Out;
> >
> > Now if you write
> >   IMPORT Out, Debug := Out;
> > whether the compiler parses it from left or right, the semantics stays
> the same, namely
> >   CONST
> >      Out = import.Out;
> >      Debug = import.Out;
> >
> > I see the LHS and RHS in different scopes.
> >
> > br
> > J rg
> >
> >>> Am 13.07.2020 um 19:17 schrieb J rg <joerg.straube at iaeth.ch>:
> >>>
> >>> ?Karl
> >>>
> >>> I agree that the import implementation of the compiler in ProjectOberon
> is too simplistic.
> >>> We had this discussion already and Andreas provided a solution for
> this.
> >>>
> >>> Generally speaking, the LHS and RHS of an import alias have nothing to
> do with each other.
> >>> RHS is a name of a sym file, LHS is an identifier to be used in your
> code.
> >>> The import order does/should not matter, as the implementation should
> look up the LHS and RHS in different name spaces.
> >>>
> >>> br
> >>> J rg
> >>>
> >>> ?Am 13.07.20, 18:28 schrieb "Oberon im Auftrag von August Karlstrom"
> <oberon-bounces at lists.inf.ethz.ch im Auftrag von fusionfile at gmail.com>:
> >>>
> >>>>   On 2020-07-13 17:57, Joerg wrote:
> >>> Debug output could be coded like this
> >>>    IMPORT Out, Debug := Out;
> >>> and all your debug output like Debug.Str( packet sent ) appears on
> screen.
> >>   I don't think we can (or should) rely on the import order; an Oberon
> >>   implementation could choose to import modules from right to left and
> >>   it's not obvious that a module should be allowed to be imported twice.
> >>
> >>   -- August
> >>   --
> >>   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