[Oberon] Module aliases - what is the correct way to handle them
Jörg
joerg.straube at iaeth.ch
Tue Jul 14 09:24:15 CEST 2020
Chris
Okay. We discuss three different topics here:
A) Do import aliases allow to import a module several times?
B) semantics of import aliases: IMPORT Out, Debug := Out; (* is the right occurence of Out influenced by the left Out *)
C) Is an import alias a good example to enable/disable debug output. Or even more general: how to handle debug output?
Chris’ answer is clearly related to C) And I agree, my proposal to use a stub module to disable debug output is indeed not a good example for import aliases.
My last mails to August were related to B). I think I made clear, that I’m strong supporter that the import order should not influence the semantic of IMPORT, as I see the LHS and the RHS residing in the different scopes.
Now back to topic A): the Oberon report states „If the form "M := M1" is used in the import list, an exported object x declared within M1 is referenced in the importing module as M.x
This definition does not specify, whether IMPORT M := M1, N := M1; is allowed.
Looking at other Oberon constructs like
CONST
S = “This is a funny string“;
S1 = S;
S2 = S;
or
TYPE
I1 = INTEGER;
I2 = INTEGER;
I don‘t see a reason why import aliases should forbid multiple imports.
Where could this be useful?
Perhaps not the best examples either but what about this:
Let’s assume you want to write a program comparing two sorting algos. You intend to do this
IMPORT Sort1 := Bubble; Sort2 := Quick;
You wrote Bubble already, didn‘t write module Quick yet, but want to test your graphical comparsion module already, there is nothing wrong with
IMPORT Sort1 := Bubble; Sort2 := Bubble;
br, Jörg
> Am 14.07.2020 um 04:06 schrieb Chris Burrows <chris at cfbsoftware.com>:
>
> 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
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
More information about the Oberon
mailing list