home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / misc / 3616 < prev    next >
Encoding:
Text File  |  1992-11-12  |  3.0 KB  |  63 lines
  1. Newsgroups: comp.lang.misc
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!swrinde!elroy.jpl.nasa.gov!ames!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
  3. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  4. Subject: Re: languages which allow the introduction of new operators
  5. Message-ID: <BxMCxA.3nM@mentor.cc.purdue.edu>
  6. Sender: news@mentor.cc.purdue.edu (USENET News)
  7. Organization: Purdue University Statistics Department
  8. References: <721458276@sheol.UUCP> <veit.721491920@du9ds3> <KERS.92Nov12085629@cdollin.hpl.hp.com>
  9. Date: Thu, 12 Nov 1992 20:00:45 GMT
  10. Lines: 51
  11.  
  12. In article <KERS.92Nov12085629@cdollin.hpl.hp.com> kers@hplb.hpl.hp.com (Chris Dollin) writes:
  13. >In article ... veit@du9ds3.uni-duisburg.de (Holger Veit) writes:
  14.  
  15.             ......................
  16.  
  17. >But Herman might not think of those things as ``operators''. Consider the Pop11
  18. >definition:
  19.  
  20. >    define 5 ++( x, y ); lvars x, y; x + y + 1 enddefine;
  21.  
  22. >The ``5'' is the precedence (it happens to be the same as ``+'') and makes
  23. >``++'' a (nominally infix) operator, so expressions such as
  24.  
  25. >    x ++ y, f(x) ++ g(h(y), z)
  26.  
  27. >work. But (in Pop) an operator is *just* a procedure with a pleasant calling
  28. >syntax; writing ``x ++ y'' just means ``push x, push y, call ++'' (Pop is an
  29. >open-stack language), ``x * y'' means ``push x, push y, call -'', and ``f(x)''
  30. >means ``push x, call f''. *Some* procedure calls are coded in-line, but this is
  31. >not a property of being (syntactically) operators; it is a property of being a
  32. >particular procedure, such as fast_front, or fi_+.
  33.  
  34. If you could write 
  35.  
  36. define    (x ++ y) x+y+1
  37.  
  38. I would accept that as the insertion of the ++ operator.  I would definitely
  39. allow far more complicated versions, as defining the power operator differently
  40. depending on the types of the arguments.  But I would object to any language
  41. which insists that we use a strictly stack machine.  Pushing, popping, and
  42. calling are to be avoided unless necessary.  Otherwise things just run too
  43. slowly to be of more than theoretical use.
  44.  
  45. But there are operators I would not want to consider defining in terms of the
  46. usual language primitives, because they essentially cannot be sensibly done 
  47. that way.  SOME of these may get into libraries where the user cannot use
  48. them himself, like add with carry, or simultaneous results of an operation.
  49. One should strive for semiportability, but not full portability, and in many
  50. cases the use of them would be portable, but the code would be machine.
  51.  
  52. Getting any speed out of machines requires that we think of speed in coding,
  53. rather than the fact that it is possible in principle to operate with a 
  54. stack machine with no registers.  This also ignores hardware, such as vector
  55. machines, where the use of a control register or control stream introduces
  56. basic bit operations which did not exist before, and which are utterly stupid
  57. as a means of efficient computation on a stack machine.
  58. -- 
  59. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  60. Phone: (317)494-6054
  61. hrubin@snap.stat.purdue.edu (Internet, bitnet)  
  62. {purdue,pur-ee}!snap.stat!hrubin(UUCP)
  63.