Re: No multiple dispatch in Ada95?

[stt@spock.camb.inmet.com (Tucker Taft)]

Fernando Mato Mira (matomira@di.epfl.ch) wrote:

:   I checked the reference manual. There's no multiple dispatching
: in Ada95?

:   I see no reason why a left-to-right disambiguating rule was not good enough.
:   You only add the extra dispatching complexity when the methods defined
: require it. And it should be faster than simulating it by
: a `double dispatch'. What's worse, time is already wasted checking
: for a Constraint_Error.

Multiple dispatching would require a relatively big shift away
from type-specific "primitive" operations (also called "dispatching
operations" when the type is tagged), to the "free-floating" methods
of CLOS.  In CLOS, a "generic function" has an associated set of
methods that implement it, and at run-time a selection among these
methods is made based on the actual parameters.  In single-dispatching
OOPLs (most others), each type has a set of operations and a set of
ancestors, and these are searched (at compile-time in Ada 95, C++,
Eiffel, Simula, Object Pascal, Modula-3, Oberon, ...; at run-time in
SmallTalk, Objective-C, ...).  

Visibility control in CLOS is oriented around packages, 
which have no particular connection with where types or methods
are declared.  Visibility control in most other OOPLs is oriented around
a module (Ada 95, Object Pascal, Modula-3, Oberon, ...) or class construct
(C++, Eiffel, SmallTalk, ...), with types and the associated operations
encapsulated by the visibility-controlling construct.

Hence, adopting multiple dispatching as in CLOS would probably require 
abandoning the Ada principle that packages provide an encapsulation of 
types and their associated operations, as well as being the basis
for visibility control.

In addition, to be efficient, multiple dispatching typically involves some 
kind of hash-based lookup at run-time.  Our philosophy for Ada 95 was that 
such operations are better implemented by the programmer, in an appropriate
application-specific way.  It is highly unlikely that the compiler
and run-time support will ever be able to match the programmer's
knowledge about a particular problem needing multiple dispatch,
so it is better for the programmer to define and implement such
an abstraction than to bury the complexity and potential unpredictable
space and time requirements in the compiler and run-time support.

Of course with CLOS, you have your Meta-Object Protocol, but that is
a *very* big bite (byte?) to swallow...

:   ... Ada got the `message send'
:   syntax right..

That's nice to hear ...

: PS: And why not reaping the benefits of both single inheritance
:    and contract-based design by restricting inheritance to
:    only one parent with structure plus an arbitrary number of abstract
:    parents with null records?

We considered this.  However, even a little bit of linguistic 
multiple inheritance introduces complexity requiring name-collision 
management, multiple virtual function tables, etc.  It is interesting 
to note that the conventional wisdom in C++ seems to be swinging over 
to emphasizing the value and importance of templates relative to 
inheritance (e.g., the new "Standard Template Library" for C++ makes only 
minimal use of inheritance, but makes heavy use of templates).  In Ada, 
generics are even more useful, because you can identify explicitly the
set of operations a formal type parameter is supposed to have.
Instantiating a generic is the most flexible kind of "interface" 
inheritance, particularly in Ada, where the operations on a type
can be effectively renamed as part of the instantiation.

Overall, our belief is that robust support for generics, plus the 
"multiple namespace inheritance" already provided by Ada's "with" 
and "use" clauses, obviates much of the need for "linguistic" support
for multiple inheritance.  Whatever is left can be readily and flexibly
handled by the sophisticated type composition facilities provided by
Ada 95, including the concept of an "access discriminant"
which allows one object to refer to another object, including
possibly its enclosing object.

: F.D. Mato Mira           http://ligwww.epfl.ch/matomira.html                  
: Computer Graphics Lab    matomira@epfl.ch 
: EPFL                     FAX: +41 (21) 693-5328

-Tucker Taft   stt@inmet.com
Intermetrics, Inc.