From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,953e1a6689d791f6 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,953e1a6689d791f6 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,953e1a6689d791f6 X-Google-Attributes: gid103376,public From: "Norman H. Cohen" Subject: Re: Eiffel and Java Date: 1996/11/01 Message-ID: <327A63DE.C4C@watson.ibm.com> X-Deja-AN: 193758834 references: content-type: text/plain; charset=us-ascii organization: IBM Thomas J. Watson Research Center mime-version: 1.0 reply-to: ncohen@watson.ibm.com newsgroups: comp.lang.eiffel,comp.lang.ada,comp.lang.c++ x-mailer: Mozilla 3.0 (Win95; I) Date: 1996-11-01T00:00:00+00:00 List-Id: 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