[Oberon] Numerical CASE Statements in Project Oberon

[Jörg Straube]

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
>> 
>> 
>>  	
>> 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.
>> 
>> 
>> 
>> --
>> 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/20151116/79d1802c/attachment.html>