Re: Multiple dispatch in Julia

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

On 12/11/2020 18:56, antispam@math.uni.wroc.pl wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On 12/11/2020 08:12, Jerry wrote:
>>
>>> I'm curious to know what Ada folks think about this discussion about Julia, especially the extended comment about multiple dispatch.
>>
>> What discussion?
>>
>> -----------
>> Like other dynamic languages claiming that they have multiple dispatch,
>> Julia deploys run-time type matching for the target method. This is all
>> you need to know.
>>
>> Because the most important requirement of properly designed dispatch
>> (multiple or not) is:
>>
>>     dispatch may never fail.
> 
> Hmm, AFAICS typical implementation of dispatch in dynamic language
> may raise error "no such method".  If error is undesired one can
> add catch all method or catch errors.  Do you think that all
> such implementations are improperly designed?

Exactly. I do not care much about dynamically typed languages as they 
are garbage per definition. But in a statically typed language if you 
declare a primitive operation you must either inherit or else override. 
Ergo, "method not understood" may never happen.

>> It is very difficult to satisfy already with multi-methods. BTW, I am
>> not sure, but it seems that Julia has only multi-methods and no full
>> multiple dispatch.
>>
>> Full multiple-dispatch is even harder to approach.
>>
>> P.S. Multi-method dispatch is something like X + Y. Both arguments and
>> the result are from the same type hierarchy. Full multiple dispatch is
>> like Print (X, Y). Arguments are from different hierarchies.
> 
> I am not sure what you want to say here.  '+' is just funny name,
> why it should be different than 'Print'?

+ is defined on, say, Matrix:

   + : Matrix x Matrix -> Matrix

You could have a hierarchy like: Band_Matrix <: Sparse_Matrix <: Matrix. 
The dispatching table is 3D with all indices corresponding to the tags 
from the same hierarchy.

Print is defined as

   Print : Device x Shape

Device may have hierarchy: Grayscale_Printer <: Color_Printer <: Device. 
Shape could be: Circle <: Ellipse <: Shape. The dispatching table is 2D 
with independent indices.

> Concerning hierarchies,
> Sevaral languages insit on "top" type, so there is only one
> hierarchy.  Other languages have several different toplevel
> types, consequently there are different hierarchies originating
> at different toplevel types.  I do not see why single hierarchy
> versus multiple hierarchies should decide if dispatch is
> multiple dispatch.

In a multi-method when you derive a new type you have full information 
about all instances of +. E.g. when you derive Band_Matrix from 
Sparse_Matrix, you already know the dispatching table at the point. You 
need only to expand it in all dimensions. There is a problem is with 
branching derivations in independent packages, but it could be fixed, I 
think.

With full dispatch, assuming separate compilation and binding, when you 
derive Circle from Ellipse, you have no idea if you must provide Print 
for Crayscale_Printer. The compiler simply does not know if it exists.

> In language I use there is type for equations.  One can add
> scalar to equation or add two equations.  This language
> uses overloading, but if another language implemented this
> via dipatch I would call it multiple dispatch.

Overloading is ad-hoc static polymorphism
Dispatch is dynamic polymorphism.

They are way different things. Static polymorphism has implicit classes 
with no objects of, only instances. Another example of is 
generics/templates.

Dynamic polymorphism has explicit classes with objects of. These in Ada 
are called class-wide objects.

>> P.P.S. Ada in fact has multi-method dispatch. It is defined so that when
>> tags of controlling arguments are different you get an exception ARM
>> 3.9.2 (16). Which, yes, violates the principle above, but nobody ever
>> pretended that Ada had multiple dispatch in the first place.
> 
> Maybe you talk about multi-method when types of arguments (or rather
> "dispatching arguments") are all equal?

Classes are equal. Types are not. The following is legal in Ada:

    type T is tagged ...;
    procedure Foo (X : T; Y : T); -- Primitive operation and multi-method

    type S is new T with ...;
    overriding procedure Foo (X : S; Y : S);


     X : T'Class := T'(...); -- The specific type is T
     Y : T'Class := S'(...); -- The specific type is S

     Foo (X, X); -- Calls Foo of T
     Foo (X, Y); -- Raises Constraint_Error
     Foo (Y, Y); -- Calls Foo of S

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