home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / misc / 3639 < prev    next >
Encoding:
Internet Message Format  |  1992-11-13  |  2.6 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!olivea!charnel!rat!usc!sdd.hp.com!hpscit.sc.hp.com!scd.hp.com!hpscdm!hplextra!otter.hpl.hp.com!hpltoad!cdollin!kers
  2. From: kers@hplb.hpl.hp.com (Chris Dollin)
  3. Newsgroups: comp.lang.misc
  4. Subject: Re: languages which allow the introduction of new operators
  5. Message-ID: <KERS.92Nov13100411@cdollin.hpl.hp.com>
  6. Date: 13 Nov 92 10:04:11 GMT
  7. References: <721458276@sheol.UUCP> <veit.721491920@du9ds3> <KERS.92Nov12085629@cdollin.hpl.hp.com> <BxMCxA.3nM@mentor.cc.purdue.edu>
  8. Sender: news@hplb.hpl.hp.com (Usenet News Administrator)
  9. Organization: Hewlett-Packard Laboratories, Bristol, UK.
  10. Lines: 45
  11. In-Reply-To: hrubin@pop.stat.purdue.edu's message of Thu, 12 Nov 1992 20:00:45 GMT
  12. Nntp-Posting-Host: cdollin.hpl.hp.com
  13.  
  14. In article ... hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
  15.  
  16. [Remarking on my Pop example with ``define 5 ++ (x, y) ...''
  17.  
  18.    If you could write 
  19.  
  20.    define    (x ++ y) x+y+1
  21.  
  22.    I would accept that as the insertion of the ++ operator.  
  23.  
  24. Well, it seems that this is just a quibble over an (admittedly unpleasant)
  25. definition syntax; I've just checked and conformed that
  26.  
  27.     define 5 x ++ y; lvars x, y; x + y + 1 enddefine;
  28.  
  29. is an acceptable form (the ``lvars'' are required for historical reasons; the
  30. Pop9X standard may well make them the default for formal parameters). There are
  31. good Popish reasons for needing the precedence annotation.
  32.  
  33.    I would definitely
  34.    allow far more complicated versions, as defining the power operator 
  35.    differently depending on the types of the arguments.  
  36.  
  37. Steve Kinght's ``objectclass'' will allow this, although I don't recall whether
  38. it allows operator definitions too. [Discussion on Pop can now take place on
  39. comp.lang.pop, yipee!]
  40.  
  41.    But I would object to any language
  42.    which insists that we use a strictly stack machine.  Pushing, popping, and
  43.    calling are to be avoided unless necessary.  Otherwise things just run too
  44.    slowly to be of more than theoretical use.
  45.  
  46. Pop doesn't insist on a stack *machine*, but it's *model* is stack-based. A Pop
  47. compiler is entitled to elide pushes, pops, and calls where the difference
  48. cannot be seen. But Pop the language is, ineluctably, stack-based, and I wasn't
  49. suggesting that Herman code in Pop; I was pointing out that what the rest of
  50. the programming community see as ``user-defined operators'', and what Herman
  51. means by ``u. d. o's'', are *different things*, and suggesting we agree on some
  52. language. 
  53.  
  54.  
  55. --
  56.  
  57. Regards,    | "Layered protocols give the software implementor a chance to
  58. Kers.       | ruin his performance in each layer." - Don Gillies
  59.