🚀 go-pugleaf

Also sprach Marc Brandis (brandis@inf.ethz.ch):
>I said:
>>As I recall Wirth's paper, the reason he gave for removing
>>enumerates was that he wanted to keep down compiler in size.
>
>This is certainly wrong, and the evidence that Richard Bielak found is
>correct. Let me cite what Wirth said in "From Modula to Oberon".

I stand by my word. Wirth talks a little in circles and gives some
half-hearted excuses at first, and then concludes with some not
far from what I said:

>       This exceptional rule defies conceptual simplicity and
>	causes unpleasant problems for the implementor.

>When you look at where enumerations are used in programs, you will notice that
>in a extensible software environment like Oberon, you definitely want to be
>able to extend these constructs. You can easily do this when using INTEGERS
>together with constants (just define some additional constants), but it is not
>that easy when having enumerations in the language.

Like in one module I have:

   CONST Red = 1;  Blue = 2;  Green = 3;  Yellow = 4;

and in another I extend this "type" with

   CONST  Black = 5;  White = 6;

Now, back in the original module I realize I need Orange too and
add Orange = 5; to the list. Either I remember to change the
values for black and white, or I don't. Easy? For the compiler
writer, sure. For me? Error prone and difficulties just becuase
someone was lazy when he defined the language.

A similar problem is the following:

  TYPE Colours = (Red, Green, Blue);
       Fruits  = (Apple, Orange, Pear);
  VAR  C : Colour;
       F : Fruit;
  BEGIN
    ...
    C := F;

In Pascal and Modula this won't compile beacuse of the type conflict.
But in Ob(solet)eron we would have

  CONST Red = 1; Green = 2; Blue = 3;
        Apple = 1; Orange = 2; Pear = 3;
  TYPE Colours = integer;
       Fruits  = integer;
  VAR  C : Colour;
       F : Fruit;
  BEGIN
    ...
    C := F;

which, unless the typing rules are different to Pascal, compiles just
fine, but isn't correct for five seconds.

>Now, what would the value of an
>instance of an extended type seen as the base type? E.g.
>
>	TYPE
>	  Colors = (red, green, blue);
>	  MoreColors = (Colors)(yellow);
>
>Now assume that you have an instance of MoreColors with the value yellow. What
>is now the value of this variable when seen as a Colors?

Assume that you have an uninitialized instance of Colours with the numeric 
value 62. What value does it have? Answer: out of range.

>To your statement about smaller and simpler compilers, and Wirth's obsession,
>I have to add something. First, as you may have found yourself: smaller and
>simpler programs are easier to maintain and to write and contain less bugs!

And are usually less useful.

>Wirth's idea is to weight cost against win, as every good engineer should do.
>I think that it is time for the software industry to recognize that programs
>do not become better by adding tons of features.

In this case this is just ludicrous. Sure, by keeping down the 
compiler size, you have less bugs in it. But by keeping down the
language in expressive power you 1) increase the size of the
programmer's program 2) gives him less possibilities to discover
stupid bugs early.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se
"There is only one success -- to be able to spend your life in your own way"
Christopher Morely