home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / misc / 3744 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  3.1 KB
  1. From: kers@hplb.hpl.hp.com (Chris Dollin)
  2. Date: Tue, 17 Nov 1992 09:58:26 GMT
  3. Subject: Re: languages which allow the introduction of new operators
  4. Message-ID: <KERS.92Nov17095826@cdollin.hpl.hp.com>
  5. Organization: Hewlett-Packard Laboratories, Bristol, UK.
  6. Path: sparky!uunet!utcsri!newsflash.concordia.ca!garrot.DMI.USherb.CA!uxa.ecn.bgu.edu!mp.cs.niu.edu!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!apollo.hp.com!cupnews0.cup.hp.com!scd.hp.com!hpscdm!hplextra!otter.hpl.hp.com!hpltoad!cdollin!kers
  7. Newsgroups: comp.lang.misc
  8. References: <721458276@sheol.UUCP> <veit.721491920@du9ds3> <KERS.92Nov12085629@cdollin.hpl.hp.com> <BxMCxA.3nM@mentor.cc.purdue.edu> <72171
  9. Sender: news@hplb.hpl.hp.com (Usenet News Administrator)
  10. Lines: 44
  11. In-Reply-To: throopw@sheol.UUCP's message of 14 Nov 92 02:21:03 GMT
  12. Nntp-Posting-Host: cdollin.hpl.hp.com
  13.  
  14. In article ... throopw@sheol.UUCP (Wayne Throop) writes:
  15.  
  16.    :: From: kers@hplb.hpl.hp.com (Chris Dollin) writes:
  17.    :: Message-ID: <KERS.92Nov12085629@cdollin.hpl.hp.com>
  18.    :: [...]  define 5 ++( x, y ); lvars x, y; x + y + 1 enddefine; [...]
  19.    : From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  20.    : Message-ID: <BxMCxA.3nM@mentor.cc.purdue.edu>
  21.    : [...] I would accept that as the insertion of the ++ operator.
  22.  
  23.    :: (Pop is an open-stack language), ``x * y'' means ``push x, push y,
  24.    :: call -'', and ``f(x)'' means ``push x, call f''.
  25.    : But I would object to any language which insists that we use a
  26.    : strictly stack machine.  Pushing, popping, and calling are to be
  27.    : avoided unless necessary.  Otherwise things just run too slowly to be
  28.    : of more than theoretical use.
  29.  
  30.    This is yet another case of confusing the abstract notation with a
  31.    concrete implementation.  Just because the abstract semantics has the
  32.    model of a stack is NO reason to suppose that this forces one to
  33.    implement the model using an explicit stack with explicit push and pop
  34.    operations.  (Not being intimately familiar with Pop, it may be that
  35.    Pop *does* require an explicit stack in the implementation, but that
  36.    can't be told just from what Chris said.  ...............
  37.  
  38. It is, perhaps, unfortunate in this instance that Pop's model makes it rather
  39. hard for an implementation to avoid actually having a stack. When calling
  40. system procedures (those things often thought of as ``built-ins'', like ``+''
  41. and ``=''), it should be easy enough to pass parameters via registers, rather
  42. than on the value stack. However, when calling user procedures, this is much
  43. more difficult; you don't know how many arguments they take, how many results
  44. they return, or indeed what procedure they *are* (since, by default, they're
  45. all variables to allow for incremental development and redefinition).
  46.  
  47. So, the Pop compiler is free to eliminate stack use where it can prove its not
  48. necessary. It's just that the proofs are, in general, impossible.
  49.  
  50. Any more Pop questions should be taken to comp.lang.pop.
  51.  
  52.  
  53.  
  54. --
  55.  
  56. Regards | "Always code as if the guy who ends up maintaining your code will be
  57. Kers.   | a violent psychopath who knows where you live." - John F. Woods
  58.