home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / modula2 / 1372 < prev    next >
Encoding:
Text File  |  1992-11-11  |  3.4 KB  |  72 lines
  1. Newsgroups: comp.lang.modula2
  2. Path: sparky!uunet!mcsun!news.funet.fi!network.jyu.fi!sakkinen
  3. From: sakkinen@jyu.fi (Markku Sakkinen)
  4. Subject: Re: mail delivery error
  5. Message-ID: <1992Nov11.102409.12183@jyu.fi>
  6. Organization: University of Jyvaskyla, Finland
  7. References: <9211091022.A01745@MAIL.CASI.NASA.GOV> <5897@balrog.ctron.com>
  8. Date: Wed, 11 Nov 1992 10:24:09 GMT
  9. Lines: 61
  10.  
  11. In article <5897@balrog.ctron.com> smith@ctron.com writes:
  12. >In article <9211091022.A01745@MAIL.CASI.NASA.GOV>, thutt@MAIL.CASI.NASA.GOV (thutt) writes:
  13. >> ...
  14. >I wouldn't classify enumerations as "superfluous", their removal is a real
  15. >loss.  But I think the real reason they went was because they are so difficult
  16. >to type-extend.  Type-extension is Oberon's "thing", and it would be most
  17. >difficult to set up a mechanism wereby various enumerations were derived from
  18. >previously-defined enumerations, where certain identifiers are valid for all,
  19. >but not all identifiers are.
  20.  
  21. That has obviously been the main reason for eliminating enumerations.
  22. And even this rationale is very weak.  Only record types can be extended
  23. in Oberon, not atomic types nor arrays.
  24.  
  25. > ...
  26. >>      c) generic SET OF: Since there is no enumeration, what are you to make
  27. >>      a set from?  The SET type is now equivalent to the M-2 BITSET. It is of
  28. >>      an implementation dependant size (usually at least 32 bits).
  29. >
  30. >This was Wirth not going far enough.  Without enumerations, sets really have
  31. >little utility or expressiveness over bit-pushing operators like C's.  SETS
  32. >could have been axed in favor of a slight extension of the INTEGER type.
  33.  
  34. I don't agree, especially since C has not got bit arrays.
  35. But set types have always been sadly crippled in
  36. Wirth's languages:  Pascal implementers are not required to support
  37. even the the full CHAR type as the base type for SET OF CHAR,
  38. not to speak of true SET OF INTEGER.  Fully-fledged set types could often
  39. be useful abstractions in programming.
  40.  
  41. >> ...
  42. >>      e) DEFINITION & IMPLEMENTATION merged.  Exported identifiers are
  43. >>      marked with a *.  Read-only exported variables are marked with a -.
  44. >>      Let us hope they make a read-only VAR parameter, which would be
  45. >>      useful for exported procedures that take a VAR parm for efficiency.
  46. >>      The programmer using the procedure would be guaranteed that the
  47. >>      parameter is not modified!
  48.  
  49. I have read somewhere that the parameter modes were variable vs. constant
  50. in an early version of Pascal.  That would have been much better
  51. than the current by-value vs. by-reference distinction (which should be left
  52. as an implementation issue)!
  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. Field-width denoters in the calls of the READ and WRITE quasi-procedures
  60. of Pascal spring to mind as a worse syntactic kludge, but it is
  61. nevertheless atypical.
  62.  
  63. ----------------------------------------------------------------------
  64. Markku Sakkinen (sakkinen@jytko.jyu.fi)
  65.        SAKKINEN@FINJYU.bitnet (alternative network address)
  66. Department of Computer Science and Information Systems
  67. University of Jyvaskyla (a's with umlauts)
  68. PL 35
  69. SF-40351 Jyvaskyla (umlauts again)
  70. Finland
  71. ----------------------------------------------------------------------
  72.