Xref: utzoo comp.lang.modula2:666 comp.lang.misc:1116
Path: utzoo!mnetor!uunet!mcvax!enea!sommar
From: sommar@enea.se (Erland Sommarskog)
Newsgroups: comp.lang.modula2,comp.lang.misc
Subject: Re: From Modula to Oberon
Message-ID: <2787@enea.se>
Date: 1 Mar 88 19:20:26 GMT
References: <7161@sol.ARPA>
Reply-To: sommar@enea.UUCP(Erland Sommarskog)
Followup-To: comp.lang.misc
Organization: ENEA DATA AB, Sweden
Lines: 96
Keywords: Enumerations, subranges, arrays, FOR, Eiffel


First, Lawrence, thank you for posting Wirth's paper. It was 
interesting to read.

So Wirth has designed a new language. If he continues in this
direction he's going to end up with C next time :-) That is
to say I am not impressed. OK, the extended type facility is
a nice feature, but principally it's just another way of
expressing prefix classes, well-known from Simula. A somewhat
different approach is Ada's generic packages with private-
type parameters.

He seems to have got simplifications in the compiler on his
mind, totally ignoring that a simplification in the compiler may
end up as more work for the poor programmer. Of the restrictions
he has made, I'd like to particulary question four of them: 
enumeration types, subranges, array indexes and for-statements.

Kent Paul Dolan has already given good arguments for keeping 
enumeration types, so I won't reapeat , jsut strongly agree. However, 
I don't share Kent's ideas on how to refer to imported enumration 
values. That would lead to code like:
     Case Action of
        Module1.Action_type.Action1 : Do_something;
        Module1.Action_type.Action2 : Do_something_else;
        ...   
Talk about meaningless verbosity!

Wirth's argument for removing subranges is really short-cutting.
No one uses packing, and just guarding isn't sufficient enough,
he says in essence. Well, it is. Not the least when you remove
enumeration. If you had subranges, you could at least protect your 
now integer-coded enumrates from illegal values due to assigning 
from uninitiated variables.

I don't fully understand the passage on arrays. He says that indexes
are integers "by default". Does this mean you could have a character
index if you like? The rest of the passage doesn't seem to admit it.
And that is a miss, I think. 
  The idea of having all arrays starting on index zero is really to
put the burden on the programmer. If Wirth really must have a fixed
lower index, he could at least have chosen one! How many of you do
often use arrays with zero as the lower bound? I do it very seldom.
And his argument about saving execution time for index computation
is truely naive. The result will just be references like:
    String(char_no + 1), 
just making the code more verbose and complex for no use.

The removal of the FOR-statement is also questionable. This means
that all loops must be done with WHILE (or REPEAT?). WHILE is more 
error-prone than FOR, since there are more things that the programmer
has to take care of. 
  And particulary in Pascal, and I guess also Modula, a certain mistake 
may have disastrous consequences:
    PROCEDURE A;
    VAR i : integer;
       PROCEDURE B;
       BEGIN
          FOR i := 1 TO Max DO
             Something;
       END;
    BEGIN
       FOR i := 1 TO Max DO
          B;
    END;
Since we forgot to declare i in B, B will be called only once. (OK, 
depends on how FOR is implemented, but replace with WHILE and there is
no doubt.) Most Pascal implementions help to save you from this by 
allowing an arbitrary order of the declarations, so we can desclare i
just before A's body. (How about Modula and Oberon?)
  Here I can't keep from mentioning Ada. In Ada the loop variable is 
declared in the FOR statement as such. Now, if only things like
   FOR i IN Array_range WHILE A(i) /= 0 LOOP
had been allowed... 

Wirth also talks about the importance of the description being concise.
My doubts here. OK, "Programming in Modula-2" may not count as the
description, but I recall it as truely drivelling in many parts. (Also,
reading it directly after going through the Ada RM, was like drinking 
diluted lemonade.) And his code examples were about unreadable, on top
of all being set with a proportional font!

We had an discussion on "Modern languages" a while ago, me being guilty.
A current trend in language design seem to the removal of long-ago
accpted constructs. Oberon drops enumerations, Eiffel has no arrays.
The only difference is that while Oberon leaves no substitions except
integer constants, Eiffel provides arrays as a standard class. Also,
Eiffel, does really introduce something new: Multiple inheritence.
Missing in many OO-languages as Simula, Smalltalk and also Oberon.


-- 
Erland Sommarskog       
ENEA Data, Stockholm        
sommar@enea.UUCP           "Souvent pour s'amuser les hommes d'equipages
                            and it's like talking to a stranger" -- H&C.