Re: Operation can be dispatching in only one type

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Mon, 16 Nov 2009 09:43:06 -0800 (PST), Adam Beneschan wrote:

> By the way, for a while I was considering requesting a language change
> to allow this sort of restricted multiple dispatch, in cases where a
> primitive operation of two types could be declared and inherited for
> two derived types that are derived in the same package, and when
> dispatching, the program would check to make sure the two actual types
> really were declared in the same package.  This would avoid having to
> deal with M x N combinations of types---something that I think is an
> issue with MI---since it only deals with pairs (or triplets, etc.) of
> types that are defined to "go together".

But you still have these combinations independently on where you derive.
You allow the "diagonal" of the full dispatching table. I.e. the
combinations:

A1, B1,
A2, B2,
A3, B3

But other combinations are still there, because they can be spelt. It is
just so that they raise Constraint_Error. This "diagonal" behavior is what
we already have for multi-methods (a form of MD with only one hierarchy
A=B). I suppose this is one of the motivations of your proposal.

But the problem with "diagonal" dispatch is that it is inconsistent with
the idea of static typing. I would insist on the design rule that dispatch
shall never fail in a legal program. I.e. the compiler shall enforce all
possible combinations of types no later than at compile time. Further, it
shall not "invent" broken implementations. In "diagonal" dispatch it would
do (and does) exactly this, it would override A1, B2 with an implementation
raising Constraint_Error.

At the same time the case represented by "diagonal" dispatch is very
important in other situations, like parallel hierarchies of types. E.g.
when we wanted to force a new instance from B'Class for each new instance
from A'Class. But again that enforcement shall be static. BTW, it is not
multiple dispatch. Technically this is rather single dispatch where the
tuple of types (A, B) is considered as root of some class of tuples, in
which (A1, B1), (A2, B2) are instances. Presently we have nothing in the
language to handle this (except the jack-of-all-trades, generics). It would
be interesting to speculate how tuples can be supported in Ada, especially
their flattening in the arguments lists, and using tuples as multiple
results of a function.

> I could try to write a
> proposal if there's enough interest, but I think it's too late to get
> into the next language revision.

I am incredibly interested in MD (and in tuples as well), but I think we
should not touch it until we knew how to do it right.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de