No multiple dispatch in Ada95?

No multiple dispatch in Ada95?

[Fernando Mato Mira]

Hello,

  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.

  I have to leave CLOS for a year. I would have exchanged multiple
inheritance for multiple dispatch. Now it's not clear that the effort
or risk of choosing Ada95 instead of C++ (yuck!) is worth it.
  [Yes, I know C++ is risky _by design_]

  Really big goof, and it's a pity given that Ada got the `message send'
  syntax right..


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?

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

Re: No multiple dispatch in Ada95?

[Mark A Biggar]

In article <3lu8tp$eep@disunms.epfl.ch> matomira@di.epfl.ch (Fernando Mato Mira) writes:
>  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.

The major reason for leaving out multiple dispatch is that given
the limitations that would have to be put on it it would be practically
useless.  Note that the only dispatching operations in Ada95 are 
the primitive operation of the tagged type and those can only be
defined in the same package spec as the tagged type declaration itself
and even then only until you do something to freeze the type (like
derive another type from it).  So once you derive a new tagged type from
an old one you can now longer define dispatching operaton on the parent type.
This means that if, for example, I had tagged types A and B with new type
C derived from A and D derived from B and the multiple dispatching operator
F(A, B), then only new dispatching version I can define is F(C, D).  If
I define F(A, D) it wouldn't be dispatching on A and likewise F(C, B)
wouldn't be dispatching on B.  And even then all that would have to be
defined in the same package spec.  Basically adding multiple dispatch to 
the language would require redisigning the whole tagged type system.

>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?

That solves the duplicate data member problem but doesn't solve the duplicate
operation problem.

--
Mark Biggar
mab@wdl.loral.com

Re: No multiple dispatch in Ada95?

[Fernando Mato Mira]

In article <1995Apr6.163750.11289@wdl.loral.com>, mab@dst17.wdl.loral.com (Mark A Biggar) writes:

> useless.  Note that the only dispatching operations in Ada95 are 
> the primitive operation of the tagged type and those can only be
> defined in the same package spec as the tagged type declaration itself
> and even then only until you do something to freeze the type (like
> derive another type from it). 

I was also dissapointed by this. I found that the inability of
defining a new virtual for a set of classes without access to
source code is a slap in the face to reuse (of couse, such new operations
should live in a different package, to avoid problems when you get
a new release of that library).


> That solves the duplicate data member problem but doesn't solve the duplicate
> operation problem.

I know. I was not looking at name clash problems. Eiffel does just fine,
and its solutions to the latter are less of an efficiency concern
as the support for multiple inheritance of data members.

BTW, hierarchical packages are cool. I argued about this some time
ago in comp.lang.lisp, and I was happy to see them in Ada95

Given the quest of both lispers and ada fans for _The_Right_Thing_
(with a different set of values), the support for multiple dispatching
in both would have made a nice parallel and a good delivery
option when MOP or dynamic features were not required.
And given that the DoD puts money in Lisp projects, too, that might
have looked interesting to them.. Oh, well..*sigh*

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

Re: No multiple dispatch in Ada95?

[Norman H. Cohen]

In article <3m3c72$5ms@disunms.epfl.ch>, matomira@di.epfl.ch (Fernando
Mato Mira) writes: 

|> I was also dissapointed by this. I found that the inability of
|> defining a new virtual for a set of classes without access to
|> source code is a slap in the face to reuse (of couse, such new operations
|> should live in a different package, to avoid problems when you get
|> a new release of that library).

I don't understand the problem.  You can derive from a tagged type in a
child of the package in which that type is declared, inheriting the
operations of the original and adding others.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: No multiple dispatch in Ada95?

[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.

Re: No multiple dispatch in Ada95?

[Robert Dewar]

Just so I am not misunderstood, when I "complained" about the complexit
of CLOS, I was specifically referring to the Meta-object protocol, which
is quite a challenge even for those with a taste for complex things!

It is quite true that a simple level of multiple dispatching could have
been implemented. We actually looked into this in considerable detail
in the Griffin project at NYU, but our final conclusions were very close
to those posted by Tuck in reference to adding MD to Ada.

I think this is one place where Tuck probably made the cut correctly. After
all it is interesting that Tuck (not known for his fear in the face of
complexity :-) never seriously suggested adding this feature, because he
felt from the start that it did not fit well without major conceptual and
language changes.

Oh-oh, I just realized that the last para could be read to mean I imply that
Tuck didn't make the right cut anywhere else. I certainly didn't mean that.
There are perhaps just 1 or 2 places where I would have liked the cut a 
little differently (I still miss in out parameters on functions), but only
1 or 2 :-)

Re: No multiple dispatch in Ada95?

[Robert Dewar]

Well that's amusing! someone says it is a "really big goof" to leave out
multiple dispatching. Well I guess this is to be expected from a CLOS
refugee :-)

But just for the record, this was not some accidental oversight, it was
certainly discussed, and here was NO (as in ZERO) support for even
considering this additional complexification.

For those who don't know CLOS, if you are bored with the excessive simplicity
of the Ada OO model, this should be a good antidote :-)

Re: No multiple dispatch in Ada95?

[Fernando D. Mato Mira]

In article <dewar.797220733@schonberg>, dewar@cs.nyu.edu (Robert Dewar) writes:

> Well that's amusing! someone says it is a "really big goof" to leave out
> multiple dispatching. Well I guess this is to be expected from a CLOS
> refugee :-)

Smalltalk-raised, custom `object-oriented C' hacker, Eiffel 2.3-molded,
CLOS/MOP refugee and C++ victim! :-)

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