home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / modula2 / 1369 < prev    next >
Encoding:
Internet Message Format  |  1992-11-10  |  3.1 KB
  1. Path: sparky!uunet!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!noose.ecn.purdue.edu!samsung!balrog!ctron.com
  2. From: smith@ctron.com (Lawrence C Smith)
  3. Newsgroups: comp.lang.modula2
  4. Subject: Re: mail delivery error
  5. Message-ID: <5897@balrog.ctron.com>
  6. Date: 10 Nov 92 17:51:08 GMT
  7. References: <9211091022.A01745@MAIL.CASI.NASA.GOV>
  8. Sender: usenet@balrog.ctron.com
  9. Reply-To: smith@ctron.com
  10. Organization: Cabletron Systems, Inc.
  11. Lines: 52
  12. Nntp-Posting-Host: glinda
  13.  
  14. In article <9211091022.A01745@MAIL.CASI.NASA.GOV>, thutt@MAIL.CASI.NASA.GOV (thutt) writes:
  15.  
  16. >   1) Removal of superfluous items:
  17. >      a) Enumerations:  They do not add enough expressiveness to a program
  18. >      to warrant the added complexity in the compiler.  For the most part,
  19. >      if you are using modules in a good fashion, you can use constants in
  20. >      the place of enuerations.  The only drawback to this is that of
  21. >      type-checking.
  22.  
  23. I wouldn't classify enumerations as "superfluous", their removal is a real
  24. loss.  But I think the real reason they went was because they are so difficult
  25. to type-extend.  Type-extension is Oberon's "thing", and it would be most
  26. difficult to set up a mechanism wereby various enumerations were derived from
  27. previously-defined enumerations, where certain identifiers are valid for all,
  28. but not all identifiers are.
  29.  
  30. >      b) Nested modules:  Discovered to be hardly used, and thus removed
  31.  
  32. I used 'em, but it makes more sense to make modules the unit of compilation,
  33. and not worry about nesting them.  A useful simplification.
  34.  
  35. >      c) generic SET OF: Since there is no enumeration, what are you to make
  36. >      a set from?  The SET type is now equivalent to the M-2 BITSET. It is of
  37. >      an implementation dependant size (usually at least 32 bits).
  38.  
  39. This was Wirth not going far enough.  Without enumerations, sets really have
  40. little utility or expressiveness over bit-pushing operators like C's.  SETS
  41. could have been axed in favor of a slight extension of the INTEGER type.
  42.  
  43. >      d) FOR statement removed in Oberon.  It is reinstated in Oberon-2.
  44.  
  45. Wirth discovered that counting loops really are a primitive construct.
  46.  
  47. >      e) DEFINITION & IMPLEMENTATION merged.  Exported identifiers are
  48. >      marked with a *.  Read-only exported variables are marked with a -.
  49. >      Let us hope they make a read-only VAR parameter, which would be
  50. >      useful for exported procedures that take a VAR parm for efficiency.
  51. >      The programmer using the procedure would be guaranteed that the
  52. >      parameter is not modified!
  53.  
  54. This was a really bad move.  Now you can't define the interface separately
  55. and enforce it, and the "*" and "-" stuff is really kludgy, very atypical
  56. of Wirth's work.  Even if you accept that merging the def and imp is good,
  57. interface details like READONLY really deserve their own keywords.
  58.  
  59. Just about the best language money can buy, though. All it needs is a good
  60. exception-handling mechanism to be ready to take on all comers.
  61.  
  62. Larry Smith (smith@ctron.com)  No, I don't speak for Cabletron.  Need you ask?
  63. -
  64. Liberty is not the freedom to do whatever we want,
  65. it is the freedom to do whatever we are able.
  66.