home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / misc / 3795 < prev    next >
Encoding:
Text File  |  1992-11-19  |  4.1 KB  |  81 lines
  1. Newsgroups: comp.lang.misc
  2. Path: sparky!uunet!elroy.jpl.nasa.gov!swrinde!zaphod.mps.ohio-state.edu!caen!hellgate.utah.edu!lanl!cochiti.lanl.gov!jlg
  3. From: jlg@cochiti.lanl.gov (J. Giles)
  4. Subject: Re: adding new operators on the fly
  5. Message-ID: <1992Nov19.190207.5297@newshost.lanl.gov>
  6. Sender: news@newshost.lanl.gov
  7. Organization: Los Alamos National Laboratory
  8. References: <1992Nov13.155126.3660@linus.mitre.org> <722061125@sheol.UUCP> <MOSS.92Nov19094411@CRAFTY.cs.cmu.edu>
  9. Date: Thu, 19 Nov 1992 19:02:07 GMT
  10. Lines: 69
  11.  
  12. In article <MOSS.92Nov19094411@CRAFTY.cs.cmu.edu>, moss@cs.cmu.edu (Eliot Moss) writes:
  13. |> I contend that when adding new operators it is much too confusing to allow the
  14. |> user to choose/define precedence (at least), thoough associativity and
  15. |> commutativity are less of a problem. The point is that it gets too complicated
  16. |> for someone trying the READ the program and understand it. Rather, it is
  17. |> likely better to take the approach of APL and Smalltalk: define one simple
  18. |> evaluation order and otherwise require parenthesization.  [...]
  19.  
  20. This is why I hedged about precedence in my last article.  I disagree that
  21. there should be no precedence (as in SmallTalk or APL).  On the other hand,
  22. I also see very little value in allowing user-defined operators to be given
  23. arbitrary precedence relationships.  I will give my actual opinion now:
  24.  
  25. The precedence of the following operators should be in this order:
  26.  
  27.       `^'     --  the exponentiation operator has highest precedence
  28.       `*' `/' --  the multiply and divide on numeric types
  29.       `+' `-' --  the add and subtract as well as unary minus and plus
  30.       `<' `<=` `==' `~=' `>=' `>'  -- relionals
  31.       `~'     --  boolean/bitwise NOT
  32.       `/\'    --  boolean/bitwise AND
  33.       `\/' `><' --  boolean/bitwise OR and XOR
  34.  
  35. All but the boolean operators should be defined for operands of any 
  36. numeric types - including mixed-mode (putting aside, for the moment, 
  37. the branch cut problems involved with complex exponents).  The boolean 
  38. operators are bitwise if the operands are integer types, and are boolean
  39. if the operands are boolean.
  40.  
  41. Now, character string operators for comparison have the same precedence
  42. as the numeric comparisons.  The only other string operator is concatenation
  43. which is the highest precedence string operator (and has *no* precedence
  44. relative to the numeric operators since they can't be used together anyway).
  45.  
  46. User defined numeric types may have the usual operators overloaded to
  47. support them.  These overloaded operators will retain the same precedence
  48. they have for the intrinsic numeric operators.  This rule is simple: the
  49. precedence of the above operator strings is always the same regardless
  50. of how they are overloaded in terms of meaning.
  51.  
  52. Function referece syntax, array indexing, structure selection, and the
  53. like are *not* operators and the syntax for them is independent of any 
  54. precedence relationships for expressions.
  55.  
  56. Finally, new operators (and other intrinsics I've not mentioned) have
  57. no *natural* precedence that I can discern.  And it would indeed lead
  58. to very confusing code (at least from *some* users) to allow them to
  59. define precedence for their new operators.  I'm personally biased in
  60. favor of making all user defined infix operators have the same precedence
  61. which is lower than the precedence of any intrinsic operator and to 
  62. have all user defined prefix and postfix operators (all unary operators 
  63. that is) have the same precedence which is higher than that of any 
  64. intrinsic operator.
  65.  
  66. On the other hand, I could be convinced that the precedence should
  67. default to what I said in the last paragraph, but that the user should
  68. be allowed to change anything he likes - and if the code becomes 
  69. unreadable that's the user's problem.
  70.  
  71. If you completely eliminate precedence, you might as well just give
  72. up operators and user Forth or Lisp - since your expressions will
  73. resemble those languages whether you like it or not.  On the other
  74. hand, a great many operators with a great man precedence levels
  75. is also a burden.  The best compromise is to pick a few obvious
  76. operators, set their precedences carefully, and leave the rest
  77. to the user.
  78.  
  79. -- 
  80. J. Giles
  81.