From: santas@inf.ethz.ch (Philip Santas)
Newsgroups: comp.lang.c++,comp.object
Subject: Re: Pros and cons of C++
Date: 21 Jan 93 20:08:17 GMT
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH


In article <1993Jan21.144542.20593@midway.uchicago.edu> dave@alex.uchicago.edu (Dave Griffith) writes:
> santas@inf.ethz.ch (Philip Santas) writes:
>> carroll@rockhead.cis.udel.edu (Mark C. Carroll) writes:
>>>
>>>First, there is an enormous difference between adding functions, and
>>>overriding primitive operations.
>>
>>Not if you have a way of finding the exact function you refer to.
>>C++ renames the overloaded functions, just check at the produced C code.
>>Relevant techniques have been used by Haskell for the
>>functions in the TypeClasses, and Scratchpad/Axiom for the
>>access of overloaded symbols.
>
>Argggh, you force me to come back.  The reason it complicates the formal
>is not that finding the correct bindings is difficult.  The reason that the
>formal semantics gets complicated is that previously primitive operations
>may now exhibit non-termination, abnormal return (setjmp or exceptions),
>modification of global state or stack, implementation-defined behavior,
>and ghod knows what else.  

Since in C++ you _cannot_ redefine primitive operations with means
other than macros (and we were not talking about macros), nothing of the
problems you mention occur. Notice that equalty on integers, for instance,
cannot be redefined. The reason it cannot, is that int is not a class;
you can redefine operators only in classes.

I understand that you want to substitute a symbol, say "=", with one value
all over your formalism, but the fact that you cannot do it, does not mean
that the language is complex, it means that you have to find another way
to deal with it. Furthermore, people feel comfortable with operators
like "+" and "*" which have been primitevely overloaded for reals, integers, 
etc. There is no reason why not to treat "=" in the same way.

Notice also that we deal with a non-trivial type system (I do not discuss
how it is implemented, this is another story)
Denotational semantics have elegant approaches on simple type systems,
but for more complicated ones they are confusing. Notice that by
assuming _traditional_ subclassing, you have a form of overloading "=",
since the objects have (od do not have) to coerce to the superclasses
in many cases. This overloading occurs with every link you add.

My position is that overloading of the assignement operator can be seen
as adding new links. You have not added any complexity to the system.

> If you don't think that these complicate
>formal semantics then you've never had to write one. 

As I said, they do not complicate it more, than normal, standard inheritance
does. If you think that the DSD of C++ is more complex that ST-80,
or Eiffel, then make the comparison, and show us the results.
Then you have to show that the increased complexity derives from
overloading operators like +, =, etc. BY HAND.

> Not only does the formal
>semantics need to worry about these new possibilities, so does every
>programmer (neophyte and expert).  In this case, adding functions is different
>than overriding primitives, because primitives come with garauntees of
>behaviour which are not there with user defined functions.

Yes. Primitives on _primitive types_ come with garantees.
Do not forget this.

I do not see _what_ you can garantee on user defined data types,
Have you ever tried to garantee equality on sets, by means of 
primitive definition of equality? Or equality on functions?

On the other hand, there is no way that you can prevent the _language_
from supporting standard pointer equality, no matter how much
you try to override it: it is _always_ there.  Whatever new definition
you make, is not part of the language. This is the point I'm 
trying to establish and you refuse to accept.

>[Repeated variations of the same mistake deleted...]

:-)

Philip Santas

  "In an evolving universe those who stand still are really moving backwards"
--------------------------------------------------------------------------------
email: santas@inf.ethz.ch				 Philip Santas
Mail: Dept. Informatik			   Institute of Scientific Computation
      ETH Zurich			  Swiss Federal Institute of Technology
      CH-8092 Zurich				      Zurich, Switzerland
      Switzerland
Phone: +41-1-2547478


      
Newsgroups: comp.lang.c++,comp.object