NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/lang/modula2/1384

Internet Message Format | 1992-11-14 | 5.5 KB

Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!ucbvax!MAIL.CASI.NASA.GOV!thutt
From: [e-mail] (thutt)
Newsgroups: comp.lang.modula2
Subject: Oberon-2 discussion continues
Message-ID: <[e-mail]>
Date: 13 Nov 92 14:12:24 GMT
Sender: [e-mail]
Reply-To: Modula2 List <[e-mail]>
Organization: The Internet
Lines: 105


  The discussion of Oberon continues....

  Markku Sakkinen continues the discussion of enumerations started by
  me (thutt):
  >In article <[e-mail]> [e-mail] writes:
  >>In article <[e-mail]>, [e-mail]
  > (thutt) writes:
  >> 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.

  > That has obviously been the main reason for eliminating enumerations.
  > And even this rationale is very weak.  Only record types can be extended
  > in Oberon, not atomic types nor arrays.

  The ability to extend enumerations did play a role in their demise,
  however it was of a limited role.  (For the record, enumeration
  extension has been implemented at ETH but removed (according to one
  person in ETH involved in the Oberon compilers)).

  To see, rationally, why enumerations were removed, we must ask
  ourselves, of what use is an enumeration?  Well, they are good for
  enumerating items, and allowing good type checking.

  It turned out, according to ETH, that enumerations were filling this
  goal, but they were also filling up a program with unecessary types
  and identifiers.  This eventually detracted from a program's
  readability.

  Several key features of Oberon also make enumerations less valuable.
  For example, (as someone pointed out), enumerations are often used to
  discrimnate variants in records.  Oberon's record extension and type
  testing disolve the need for this capability.

  Using the module concept, and encapsulating your procedure parameters
  as `messages' to the data structure obviates the need to have
  enumerated parameters to a function.

  If you must enumerate something (mouse buttons, for example), and
  your program is well designed (modularized), there is no reason why a
  constant cannot be used in the place of an enumeration.  If you doubt
  this, take a look at the source for the Oberon project
  (neptune.ethz.ch, directory /Oberon/???)

  >>> c) generic SET OF: Since there is no enumeration, what are you to make
  >> 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.
  > I don't agree, especially since C has not got bit arrays. But set
  > types have always been sadly crippled in Wirth's languages:  Pascal
  > implementers are not required to support even the the full CHAR type
  > as the base type for SET OF CHAR, not to speak of true SET OF
  > INTEGER.  Fully-fledged set types could often be useful abstractions
  > in programming.

  There you go again.  It seems that many of the people who are
  complaining about Oberon are not focused on the goal.  Without trying
  to start an RWAR & keeping in mind the `Make it as simple as
  possible, but no simpler' adage used in the Oberon project, your call
  for a SET OF n is unfounded.

  The goal of Oberon was to reduce the features in a language that are
  _strictly_ unneccessary.  Couple this with the performance hit of a
  generic set (runtime & compiler complexity), and you can see that it
  is not worth the effort.  By adding features to a language in a
  haphazard manner, you will end up with C++, or something like
  Modula-3.

  >>>  e) DEFINITION & IMPLEMENTATION merged.

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

  No, this is a good move.  The maintenance of only 1 file is a big
  win.  If you are concerned about the definition being published with
  the source, don't worry.  There is a `Browser' module which will
  output a definition for a compiled module.  You can then ship the
  defintion (sans comments, unless you provide them) with your object
  modules.


  Larry Smith points out:
  >> d) FOR statement removed in Oberon.  It is reinstated in Oberon-2.
  > Wirth discovered that counting loops really are a primitive construct.

  Counting loops are indeed primitive.  That is what LOOP, REPEAT and
  WHILE accomplish.  I think the FOR loop was readded as syntactic
  convenience.  They should have made the FOR loop more like ADA, that
  is, with a _true_ induction variable.

  He also points out that it is the best language to be found.  Agreed.
  Exception handling would be nice, but is not _strictly_ needed.

  Incidentally, ASSERT is now a standard procedure in Oberon.

  Taylor
  [e-mail]
  Championing worldwide usage of Oberon-2