Re: Eiffel and Java

["Norman H. Cohen" <ncohen@watson.ibm.com>]

Joachim Durchholz wrote:
> 
> jsa@alexandria wrote 30.10.96:
> 
> > 3) the function notation allows Ada to dispatch based on the _result_ of
> >    parameter which is a function call.  Or has the function dispatch to
> >    the right thing based on the other parameters.  Bob Duff gave a couple
> >    of nice examples of this:
> 
> Actually, I see this as a *flaw* in Ada.
> 
> Yes, it allows one to play some neat and useful tricks with dispatching.
> 
> But it also allows totally ambiguous expressions. Example:
> Let's have fictitious types INT and LONGINT, with the obvious operator
> definitions
>   INT + INT -> INT               (1)
>   INT + INT -> LONGINT           (2)
>   INT + LONGINT -> LONGINT       (3)
>   LONGINT + INT -> LONGINT       (4)
>   LONGINT + LONGINT -> LONGINT   (5)
> However, this is ambiguous in an expression like
>   (INT + INT) + LONGINT
> because there are two possible interpretations:
>   (INT +(1) INT) +(3) LONGINT
> and
>   (INT +(2) INT) +(4) LONGINT

It appears that your are confusing the compile-time issue of overloading
with the run-time issue of dispatching.  Dispatching a function call
based on the required result type can only occur with tagged types, only
when the function call has no PARAMETERS controlling dispatching, and
only when the function call its itself a parameter of some surrounding
dispatching subprogram call.

The issue you address above is overloading, i.e., the declaration of
multiple subprograms with the same name, resolved at compile time based
on the types of parameters and function results.
 
> I'm not sure how Ada handles such cases. Solution (a) might be a compiler
> error as soon as the compiler detects potentially ambiguous operator (or
> function) declarations, solution (b) might be disambiguating rules.

Ada uses solution (a), but provides mechanisms by which a programmer can
provide disambiguating hints.  In practice, most of the time,
overloading just "does the right thing" that a programmer would naively
expect, and provides a succinct, natural notation.  Occasionally, a
programmer is surprised by an error message indicating that his
expression is ambiguous, in which case he adds disambiguating
information (such as enclosing an operand in a "qualified expression"
indicating its type), obtaining a slightly less succinct but unambiguous
expression.  Thus, if I1 and I2 are of type Integer and LI is of type
Long_Integer and, after declaring the five versions of "+" in your
example you write the expression I1+I2+LI (in a context where a
Long_Integer value is expected), the compiler will reject the expression
as illegal.  You can disambiguate the expression by writing either

   Integer'(I1+I2) + LI

or

   Long_Integer'(I1+I2) + LI

depending on which you mean.

It is indeed possible for a programmer to increase the likelihood of
ambiguities by creating too many overloaded functions involving the same
types.  Your example is not a good one because generally accepted Ada
style is to introduce multiple integer types only to reflect multiple
abstract notions, e.g. screen coordinates and port numbers; on the
occasions when it is necessary to intermix multiple  types, a good Ada
programmer writes an explicit conversion--

   LI2 := Long_Integer(I) + LI1;  
      -- I of type Integer; LI1 and LI2 of type Long_Integer

-- rather than declaring a version of "+" with a Long_Integer left
operand, an Integer right operand, and a Long_Integer result.  A better
example is a type Rational, an abstract data type for rational numbers
(probably implemented in terms of an integer numerator and a positive
integer denominator in lowest terms).  The usual arithmetic operators
can be overloaded for this type, to take one or two Rational operands
and produce a natural result.  This is a very natural and appropriate
use of overloading, allowing one to write

   A(I,J) := A(I,J) - A(I,I)*A(Pivot_Row,J);

rather than

   A(I,J) := 
      Rational_Difference
         (A(I,J),
          Rational_Product(A(I,I), A(Pivot_Row, J)));

It doesn't get you into trouble into you decide that you would also like
to overload "/" to act as a constructor for type Rational, taking two
operands of type Integer and returning a Rational result.  Now the
statement

   R := (I1/I2) / (I3/I4);
      -- R is of type Rational; I1, I2, I3, and I4 are of type Integer

becomes ambiguous.  It can be disambiguated by writing any of the
following:

   R := Rational'(I1/I2) / (I3/I4);
   R := (I1/I2) / Rational'(I3/I4);
   R := Rational'(I1/I2) / Rational'(I3/I4);   

   R := Integer'(I1/I2) / (I3/I4);   
   R := (I1/I2) / Integer'(I3/I4);
   R := Integer'(I1/I2) / Integer'(I3/I4);
 
> Solution (a) would make it possible to break existing code by adding
> innocently-looking functions.

Possible in theory, but unusual in practice.
> 
> Solution (b) is much, much worse. It is not only harder to read
> potentially ambiguous code because you need to know more rules to
> interpret it (and disambiguating rules tend to contain arbitraryness which
> makes remembering the correct rules even harder).

Agreed.  C++ is a disaster in this respect, especially in conjunction
with the implicit conversions introduced by conversion constructors.

> It also introduces subtle changes in semantics - when a new function like
> (3) is introduced, routine calls all over the rest of the system might
> dispatch to the new function, and without an obvious hint to the
> programmer. (You can't even use a string-search tool to find all affected
> calls, because the "+" function is heavily overloaded.)

Again, this has nothing to do with dispatching, which is run-time
selection of a particular subprogram version, based on the value of an
operand's tag in a context where that value cannot be known at compile
time.
 
> I'd like to hear wether this is a real problem in Ada or wether I'm seeing
> ghosts here.

Well, let's just say that it was appropriate that you posted your
message on October 31. ;-)

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen