Re: Operation can be dispatching in only one type

[Adam Beneschan <adam@irvine.com>]

On Nov 16, 12:28 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> 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.

Since a call to a dispatching operation may have parameters that are
themselves of class-wide types, I don't think this is possible.

In Ada as it exists currently, you can declare a primitive operation
with two parameters of the same tagged type (maybe that's what you
meant by "multi-method"---sorry, I don't know the jargon).  E.g.

   type T is abstract tagged null record;
   procedure Some_Operation (Param_1 : T; Param_2 : T);

If you later call

   Some_Operation (X, Y);

and X is declared to be of type T1 (a descendant of T) and Y is
declared to be of type T2 (also a descendant of T), then the compiler
can statically determine that this will fail.  But if either X or Y
(or both) is declared to be of type T'Class, then the compiler can't
statically tell whether the dispatch will fail or not.  So a runtime
check is needed.  Similarly for the proposal I was thinking of making.


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

I don't think the proposal I was considering was a solution to MD, but
rather to a smallish subset of MD-related problems---although it was a
subset I thought would be useful, and I may have run into a case in my
own code where I would have wanted to use it.

                            -- Adam