home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / cplus / 19698 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  4.8 KB
  1. Xref: sparky comp.lang.c++:19698 comp.object:4981
  2. Path: sparky!uunet!spool.mu.edu!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!mcsun!chsun!bernina!neptune!santas
  3. From: santas@inf.ethz.ch (Philip Santas)
  4. Newsgroups: comp.lang.c++,comp.object
  5. Subject: Re: Pros and cons of C++
  6. Message-ID: <1993Jan21.200817.10226@neptune.inf.ethz.ch>
  7. Date: 21 Jan 93 20:08:17 GMT
  8. References: <1993Jan20.155100.22563@udel.edu> <1993Jan20.232007.29047@neptune.inf.ethz.ch> <1993Jan21.144542.20593@midway.uchicago.edu>
  9. Sender: news@neptune.inf.ethz.ch (Mr News)
  10. Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
  11. Lines: 90
  12. Nntp-Posting-Host: ru3.inf.ethz.ch
  13.  
  14.  
  15. In article <1993Jan21.144542.20593@midway.uchicago.edu> dave@alex.uchicago.edu (Dave Griffith) writes:
  16. > santas@inf.ethz.ch (Philip Santas) writes:
  17. >> carroll@rockhead.cis.udel.edu (Mark C. Carroll) writes:
  18. >>>
  19. >>>First, there is an enormous difference between adding functions, and
  20. >>>overriding primitive operations.
  21. >>
  22. >>Not if you have a way of finding the exact function you refer to.
  23. >>C++ renames the overloaded functions, just check at the produced C code.
  24. >>Relevant techniques have been used by Haskell for the
  25. >>functions in the TypeClasses, and Scratchpad/Axiom for the
  26. >>access of overloaded symbols.
  27. >
  28. >Argggh, you force me to come back.  The reason it complicates the formal
  29. >is not that finding the correct bindings is difficult.  The reason that the
  30. >formal semantics gets complicated is that previously primitive operations
  31. >may now exhibit non-termination, abnormal return (setjmp or exceptions),
  32. >modification of global state or stack, implementation-defined behavior,
  33. >and ghod knows what else.  
  34.  
  35. Since in C++ you _cannot_ redefine primitive operations with means
  36. other than macros (and we were not talking about macros), nothing of the
  37. problems you mention occur. Notice that equalty on integers, for instance,
  38. cannot be redefined. The reason it cannot, is that int is not a class;
  39. you can redefine operators only in classes.
  40.  
  41. I understand that you want to substitute a symbol, say "=", with one value
  42. all over your formalism, but the fact that you cannot do it, does not mean
  43. that the language is complex, it means that you have to find another way
  44. to deal with it. Furthermore, people feel comfortable with operators
  45. like "+" and "*" which have been primitevely overloaded for reals, integers, 
  46. etc. There is no reason why not to treat "=" in the same way.
  47.  
  48. Notice also that we deal with a non-trivial type system (I do not discuss
  49. how it is implemented, this is another story)
  50. Denotational semantics have elegant approaches on simple type systems,
  51. but for more complicated ones they are confusing. Notice that by
  52. assuming _traditional_ subclassing, you have a form of overloading "=",
  53. since the objects have (od do not have) to coerce to the superclasses
  54. in many cases. This overloading occurs with every link you add.
  55.  
  56. My position is that overloading of the assignement operator can be seen
  57. as adding new links. You have not added any complexity to the system.
  58.  
  59. > If you don't think that these complicate
  60. >formal semantics then you've never had to write one. 
  61.  
  62. As I said, they do not complicate it more, than normal, standard inheritance
  63. does. If you think that the DSD of C++ is more complex that ST-80,
  64. or Eiffel, then make the comparison, and show us the results.
  65. Then you have to show that the increased complexity derives from
  66. overloading operators like +, =, etc. BY HAND.
  67.  
  68. > Not only does the formal
  69. >semantics need to worry about these new possibilities, so does every
  70. >programmer (neophyte and expert).  In this case, adding functions is different
  71. >than overriding primitives, because primitives come with garauntees of
  72. >behaviour which are not there with user defined functions.
  73.  
  74. Yes. Primitives on _primitive types_ come with garantees.
  75. Do not forget this.
  76.  
  77. I do not see _what_ you can garantee on user defined data types,
  78. Have you ever tried to garantee equality on sets, by means of 
  79. primitive definition of equality? Or equality on functions?
  80.  
  81. On the other hand, there is no way that you can prevent the _language_
  82. from supporting standard pointer equality, no matter how much
  83. you try to override it: it is _always_ there.  Whatever new definition
  84. you make, is not part of the language. This is the point I'm 
  85. trying to establish and you refuse to accept.
  86.  
  87. >[Repeated variations of the same mistake deleted...]
  88.  
  89. :-)
  90.  
  91. Philip Santas
  92.  
  93.   "In an evolving universe those who stand still are really moving backwards"
  94. --------------------------------------------------------------------------------
  95. email: santas@inf.ethz.ch                 Philip Santas
  96. Mail: Dept. Informatik               Institute of Scientific Computation
  97.       ETH Zurich              Swiss Federal Institute of Technology
  98.       CH-8092 Zurich                      Zurich, Switzerland
  99.       Switzerland
  100. Phone: +41-1-2547478
  101.  
  102.  
  103.       
  104.