Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!pur-phy!hal
From: hal@pur-phy (Hal Chambers)
Newsgroups: comp.lang.misc
Subject: Re: From Modula to Oberon
Message-ID: <1008@pur-phy>
Date: 3 Mar 88 12:36:57 GMT
References: <7161@sol.ARPA> <2787@enea.se>
Reply-To: hal@newton.physics.purdue.edu.UUCP (Hal Chambers)
Organization: Purdue Univ. Physics Dept., W. Lafayette, IN
Lines: 55
Keywords: Enumerations, subranges, arrays, FOR, Eiffel

In article <2787@enea.se> sommar@enea.UUCP(Erland Sommarskog) writes:

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

Ditto.

 >So Wirth has designed a new language. If he continues in this
 >direction he's going to end up with C next time :-)

It appears just about all of us got that impression.

 >  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.

For myself, usage is split just about 50-50 between lower index 0
and lower index 1.

 >  Here I can't keep from mentioning Ada. In Ada the loop variable is 
 >declared in the FOR statement as such.

One of the features a Ada that I like! This also makes the fact that
the scope of the loop variable is confined to the loop quite explicit.

As to requiring explicit qualification to imported names, this makes it
impossible for a programmer to provide facilities which appear to extend
for language.  For example, I use my own standard io module (inspired by
Software Tools) and like to regard  open,close,putcf etc. as part of the
language.  Requiring qualification means I have to code

		stdio.open, stdio.close,   etc.

To me, this appears verbose (and adds no clarity).  If one feels that
the programmer should not be lulled into thinking that open/close ARE
part of the language then I think that requirement is satified by the
appearance of open/close in the import list:

	FROM stdio IMPORT open, close, ...

One feature of Oberon that I like alot is mixed mode arithmetic.
Requiring the programmer to provide explicit type conversion in
expressions (INTEGER,CARDINAL,TRUNC,FLOAT,...) adds to the verbosity
of the program and detracts from understanding the meaning of the
expression.

How would programmers feel if a language designer decided that a hierarchy
of implicit operator precedence was dangerous and required programmers
to always use parentheses explicitly!  Specifying an order of numeric
type precedence frees the source program of the warts mentioned above.
Note that I am only refering to type conversion within the numeric
types and NOT between CHAR, BOOLEAN, etc.

Hal Chambers