🚀 go-pugleaf

In article <9211091022.A01745@MAIL.CASI.NASA.GOV>, thutt@MAIL.CASI.NASA.GOV (thutt) writes:

>   1) Removal of superfluous items:
>      a) Enumerations:  They do not add enough expressiveness to a program
>      to warrant the added complexity in the compiler.  For the most part,
>      if you are using modules in a good fashion, you can use constants in
>      the place of enuerations.  The only drawback to this is that of
>      type-checking.

I wouldn't classify enumerations as "superfluous", their removal is a real
loss.  But I think the real reason they went was because they are so difficult
to type-extend.  Type-extension is Oberon's "thing", and it would be most
difficult to set up a mechanism wereby various enumerations were derived from
previously-defined enumerations, where certain identifiers are valid for all,
but not all identifiers are.

>      b) Nested modules:  Discovered to be hardly used, and thus removed

I used 'em, but it makes more sense to make modules the unit of compilation,
and not worry about nesting them.  A useful simplification.

>      c) generic SET OF: Since there is no enumeration, what are you to make
>      a set from?  The SET type is now equivalent to the M-2 BITSET. It is of
>      an implementation dependant size (usually at least 32 bits).

This was Wirth not going far enough.  Without enumerations, sets really have
little utility or expressiveness over bit-pushing operators like C's.  SETS
could have been axed in favor of a slight extension of the INTEGER type.

>      d) FOR statement removed in Oberon.  It is reinstated in Oberon-2.

Wirth discovered that counting loops really are a primitive construct.

>      e) DEFINITION & IMPLEMENTATION merged.  Exported identifiers are
>      marked with a *.  Read-only exported variables are marked with a -.
>      Let us hope they make a read-only VAR parameter, which would be
>      useful for exported procedures that take a VAR parm for efficiency.
>      The programmer using the procedure would be guaranteed that the
>      parameter is not modified!

This was a really bad move.  Now you can't define the interface separately
and enforce it, and the "*" and "-" stuff is really kludgy, very atypical
of Wirth's work.  Even if you accept that merging the def and imp is good,
interface details like READONLY really deserve their own keywords.

Just about the best language money can buy, though. All it needs is a good
exception-handling mechanism to be ready to take on all comers.

Larry Smith (smith@ctron.com)  No, I don't speak for Cabletron.  Need you ask?
-
Liberty is not the freedom to do whatever we want,
it is the freedom to do whatever we are able.