[Oberon] Numerical CASE Statements in Project Oberon

[Jan de Kruyf]

I just picked up something else in the ADA best practice:

"Use a sequence of assignments for an aggregation when measured performance
indicates."

And I remember now looking at ARM machine code produced by the Ada
compiler: The mess produced was quite drastic.

j.


On Wed, Nov 18, 2015 at 12:23 PM, Jan de Kruyf <jan.de.kruyf at gmail.com>
wrote:

> I missed your post Jörg, sorry about that.
> I would say, yes.
> But at the same time the CASE constructions in the compiler via IF THEN
> are very verbose, and we can only guess about the execution time.
> I agree there was no immediate need for it, but at the same time he did
> put it in the language description, so here is a riddle.
>
> On the matter of record aggregate assignments: They are fine when the
> records are 1 deep, and even recommended since the compiler helps you to
> pick up initialization errors in the case you change the record. But on
> multilevel records (a record in a record) they very quickly become a very
> big pain.
>
> In any case I do like the new WHILE, mainly because, although it might not
> execute quite as quickly as an oldfashioned loop with random exits, it does
> force me to write clearer code.
>
> Then I wanted to ask you a question or 2:
>
> 1. have you used the CASE statement to separate records by extension?
>     Can I have a base record and one extented base record and treat them
> each differently with CASE?
>     (it is my lazy day you see.)
>
> 2. Is there any other O-7 compiler except the one for the RISC environment?
>
> cheers,
> j.
>
>
> On Mon, Nov 16, 2015 at 1:48 PM, Jörg Straube <joerg.straube at iaeth.ch>
> wrote:
>
>> My 2cents:
>> I assume Wirth did include all language elements that are needed by the
>> compiler, as he may think: if you can write such a complex thing as a
>> complier with it, the language is okay.
>>
>> Eg string (= special form of array) assignments  - strictly speaking -
>> are not needed. But as the Scanner needs strings quite intensively, Wirth
>> included it in the language.
>> If you read the compiler source code, you will find out that numerical
>> array assignments are possible as well although not present in the language
>> description.
>> However Record assignments - although handy in certain cases - are not in
>> the language, as the compiler does not need them.
>>
>> The same with the numerical CASE statement. There is no immediate need
>> for it when writing the compiler.
>>
>> br
>> Jörg
>>
>> Am 16.11.2015 um 09:31 schrieb Jan de Kruyf <jan.de.kruyf at gmail.com>:
>>
>> Yes,
>> The old man has been right most of the time, I agree. And I will have a
>> royal battle to reduce the compiler construction back down to Wirthian
>> elegance, that I also realize. But at the same time the code I produce is
>> very elegant and sweet. On the basis of that I would say you are wrong in
>> your statement that IF THEN can be made as efficient as a good case
>> construct. Besides, a Case statement allows ranges like A..Z, a..z and so
>> on, this has never been part of IF THEN, while in a properly constructed
>> bin-tree it resolves itself.
>>
>> So since Wirth was first and foremost a teacher all his life, we could
>> say that there are 2 learning opportunities here
>> 1. to produce fast code.
>> 2. to construct an elegant way of doing so.
>>
>>  I think that the master himself also realized the issues you and I are
>> bringing up, and did not see his way out of the predicament yet. And since
>> he is about 80 now and since he still got a few irons in the fire this was
>> left for a bit.
>>
>> Lastly Dijkstra taught that you should never limit yourself because of
>> inefficient machines. But you should strive to generalize any language
>> design solution to as many cases as possible, even if that slows your
>> program execution down a bit. There were big arguments in the Algol design
>> meetings about that. Some people then felt that you had to live with the
>> equipment given and use it as efficiently as possible. Wirth no doubt knows
>> that whole history even better than I do. In the mean time of course, the
>> machine limitations of those days (it was the time of the vacuum tubes)
>> have been solved a hundred times over, but we still are trying to live with
>> the language limitations of some of the older languages.
>> Ergo the numerical case statement is in the O-7 language report, but is
>> has not been implemented yet.
>>
>> So I feel fully justified implementing it. The way how to, we can talk
>> about. If the Oberon community is alive and well ten I am sure that the
>> last word has not been spoken yet.
>>
>>
>> Enjoy your day
>>
>> j.
>>
>>
>>
>>
>> On Tue, Nov 10, 2015 at 3:23 PM, John Stout <JSS at kgv.ac.uk> wrote:
>>
>>> I wonder what Professor Wirth’s views might be on this.
>>>
>>>
>>>
>>> From the book The School of Niklaus Wirth (>> The Art of Simplicity<<)
>>> ISBN 1-55860-723-4, the chapter by Michael Franz called Oberon – The
>>> Overlooked Jewel:
>>>
>>>
>>>
>>> “I still vividly remember the day that With decided to replace the
>>> elegant data structure used in the compiler’s symbol table handler by a
>>> mundane linear list. In the original compiler, the objects in the symbol
>>> table had been sorted in a tree data structure (in identifier lexical
>>> order) for fast access, with a separate linear list representing their
>>> declaration order. One day Wirth decided that there really weren’t enough
>>> objects in a typical scope to make the sorted tree cost-effective. All of
>>> us Ph.D. students were horrified: it had taken *time* to implement the
>>> sorted tree, the solution was *elegant*, and it worked *well* – so why
>>> would one want to throw it away  and replace it with something *simpler*,
>>> and even worse, something as prosaic as a linear list? But of course, Wirth
>>> was right, and the simplified compiler was both smaller and faster than its
>>> predecessor.”
>>>
>>>
>>>
>>> The implementation using IF … THEN chains is simple. If the most common
>>> cases are positioned first in the chain then the execution time for these
>>> cases is minimised. The compiler will be simpler, the implementation of the
>>> ELSE (or an error) is simple to implement and the compiler will be simple
>>> and fast.
>>>
>>>
>>>
>>> Looking through the body of Oberon code that we have what is the
>>> distribution of the number of cases? I realise we are talking about a new
>>> feature, but I still favour the simple solution, in keeping with the spirit
>>> of Oberon.
>>>
>>>
>>>
>>> John Stout
>>>
>>> [image: King George V Logo]
>>>
>>> *John Stout*
>>> Management Information Systems Coordinator
>>> Tel: 01704 530601
>>> E-Mail: JSS at kgv.ac.uk
>>> Web: www.kgv.ac.uk
>>>
>>> Information contained in this e-mail is intended for the use of the
>>> addressee only and is confidential.  Any dissemination, distribution,
>>> copying or use of this communication without prior permission of the
>>> addresseeis strictly prohibited.
>>>
>>> Every effort has been made to ensure that any attachment to this mail
>>> does not contain virus. King George V College has taken every reasonable
>>> precaution to minimise this risk, neither it nor the sender can accept
>>> liability for any damage which you sustain as a result of software viruses.
>>> You should carry outyour own virus checks before opening any attachments.
>>>
>>> [image: Think Before You Print]
>>>
>>> --
>>> 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/20151118/26141f57/attachment.html>