home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / lang / cplus / 16203 < prev    next >
Encoding:
Internet Message Format  |  1992-11-13  |  4.6 KB
  1. Xref: sparky comp.lang.c++:16203 comp.std.c++:1557
  2. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!spool.mu.edu!agate!agate!matt
  3. From: matt@physics16.berkeley.edu (Matt Austern)
  4. Newsgroups: comp.lang.c++,comp.std.c++
  5. Subject: The fate of my exponentiation operator proposal
  6. Date: 12 Nov 92 23:42:42
  7. Organization: Lawrence Berkeley Laboratory (Theoretical Physics Group)
  8. Lines: 89
  9. Message-ID: <MATT.92Nov12234242@physics16.berkeley.edu>
  10. Reply-To: matt@physics.berkeley.edu
  11. NNTP-Posting-Host: physics16.berkeley.edu
  12.  
  13. A while ago, as some of you probably remember, I posted a proposal
  14. (X3J16/92-0127 and WG21/N0204) for adding an exponentiation operator
  15. to C++.
  16.  
  17. The extensions working group has considered this proposal and rejected
  18. it.  A number of people on the Net have talked about the idea of an
  19. exponentiation operator, so I thought they might be interested in
  20. hearing the reasons for this decision.
  21.  
  22. (Oh, since this is the Net, and words here are even more subject to
  23. misinterpretation than they usually are, I just want to make this
  24. clear: I am not attacking anyone, I am not accusing anyone of
  25. anything, and I am not trying to start an argument.  I really am just
  26. posting this for the reason I gave above: I thought that some people
  27. might want to know this, and might not learn it through other
  28. channels.)
  29.  
  30. The following is an excerpt from the analysis of my proposal, which
  31. was written by Dag Bruck (dag@control.lth.se).  Actually, this is
  32. pretty much the entirety of the analysis, including the comments that
  33. I made in response to it.  That's the easiest way to make sure I don't
  34. take anything out of context!
  35.  
  36. ------------------------------------------------------------
  37.  
  38. The proposal was rejected for the following reasons:
  39.  
  40. 1.  People who do not write numerical programs will probably find a
  41. C++ exponentiation operator neither beneficial nor detrimental,
  42. according to the proposal.  However, every user of C++ must learn this
  43. new feature.
  44.  
  45. 2.  An operator provides syntactic convenience, but does not provide
  46. any new functionality.  Members of the working group, representing
  47. heavy users of scientific/engineering computation, indicated that the
  48. operator syntax provides minor syntactic convenience.
  49.  
  50. 3.  Users have stressed the importance of substituting their own
  51. specialized power functions for the system default, which would not be
  52. possible with an intrinsic operator.
  53.  
  54. 4.  The proposal is not well motivated; in particular, by analyzing
  55. one 30.000 line FORTRAN program, it does not show that the operator
  56. would be widely used.
  57.  
  58. 5.  The propsal requires adding a new operator and adding another
  59. precedence level, thus increasing the complexity of the language.
  60.  
  61. Consequently, the working group did not consider that the advantages
  62. of the proposal outweigh the disadvantages.
  63.  
  64. The working group does however favour the suggestion to overload
  65. function pow() to take an integer exponent, which would become part of
  66. the standard C++ library.
  67.  
  68. Matthew Austern, the author of the proposal, comments the rejection as
  69. follows.  Some detailed comments on the causes of rejection have been
  70. omitted.
  71.  
  72. "I am glad to see that the working group supports adding operator
  73. pow(double, int) to the standard library.  Even without an
  74. exponentiation operator, this change will be a real benefit, and will
  75. rectify a noticeable omission.  As I said in my original proposal,
  76. this change will remove all arguments in favor of an exponentiation
  77. operator except for the syntactic argument.
  78.  
  79. I believe, however, that it is a mistake to dismiss the importance of
  80. syntax so readily.  Syntax matters!  Syntax is the reason why C++
  81. (unlike, for example, Objective C) supports operator overloading; for
  82. that matter, syntax is the only reason why C++ (again, unlike, for
  83. example, lisp) has operators at all.  On a smaller scale, syntax is
  84. the reason why the language was extended to permit overloading of both
  85. operator++() and operator++(int).
  86.  
  87. Users of most other languages have found the syntactic convenience of
  88. an exponentiation operator to be useful, and I see no reason why C++
  89. would be an exception.
  90.  
  91. I am sorry to see this proposal rejected because I still believe that,
  92. of the currently popular languages, C++ is probably the best suited
  93. for the type of scientific programs that I write.  The absence of an
  94. exponentiation operator, however, will make it harder for me to
  95. persuade my colleagues to that point of view."
  96.  
  97. --
  98. Matthew Austern                   Just keep yelling until you attract a
  99. (510) 644-2618                    crowd, then a constituency, a movement, a
  100. austern@lbl.bitnet                faction, an army!  If you don't have any
  101. matt@physics.berkeley.edu         solutions, become a part of the problem!
  102.