[Oberon] Numerical CASE Statements in Project Oberon

[Jan de Kruyf]

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/4ea55435/attachment.html>