home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / modula2 / 1380 < prev    next >
Encoding:
Internet Message Format  |  1992-11-13  |  1.9 KB
  1. Path: sparky!uunet!ornl!utkcs2!darwin.sura.net!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!doc.ic.ac.uk!uknet!mucs!m1!bevan
  2. From: bevan@cs.man.ac.uk (Stephen J Bevan)
  3. Newsgroups: comp.lang.modula2
  4. Subject: Re: mail delivery error
  5. Message-ID: <BEVAN.92Nov12122929@beluga.cs.man.ac.uk>
  6. Date: 12 Nov 92 12:29:29 GMT
  7. References: <9211091022.A01745@MAIL.CASI.NASA.GOV> <5897@balrog.ctron.com>
  8. Sender: news@cs.man.ac.uk
  9. Organization: Department of Computer Science, University of Manchester
  10. Lines: 29
  11. In-reply-to: smith@ctron.com's message of 10 Nov 92 17:51:08 GMT
  12.  
  13. In article <5897@balrog.ctron.com> smith@ctron.com (Lawrence C Smith) writes:
  14.  
  15.    [ much that I agree with ]
  16.  
  17.    >      e) DEFINITION & IMPLEMENTATION merged.  Exported identifiers are
  18.    >      marked with a *.  Read-only exported variables are marked with a -.
  19.    >      Let us hope they make a read-only VAR parameter, which would be
  20.    >      useful for exported procedures that take a VAR parm for efficiency.
  21.    >      The programmer using the procedure would be guaranteed that the
  22.    >      parameter is not modified!
  23.  
  24.    This was a really bad move.  Now you can't define the interface separately
  25.    and enforce it, and the "*" and "-" stuff is really kludgy, very atypical
  26.    of Wirth's work.
  27.  
  28. You could, of course, argue that the def/imp model is a "bad move"
  29. because it forces one interface on a piece of code.  There is nothing
  30. stopping me using an implementation for more than one purpose (e.g. an
  31. avl tree to implement a set or a map) by having two interfaces to it
  32. (a la signatures/structures in ML).  Personally I'm ambivalent.
  33.  
  34.    Just about the best language money can buy, though. All it needs is a good
  35.    exception-handling mechanism to be ready to take on all comers.
  36.  
  37. Hm, seems to be a bit of deja vu here :-)  Did you see/reply to my
  38. last set of questions about your view of exception handling.  I didn't
  39. see any folloup.
  40.  
  41. bevan
  42.