Re: Multiple dispatch in Julia

[antispam@math.uni.wroc.pl]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 15/11/2020 13:43, antispam@math.uni.wroc.pl wrote:
> > Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> >> On 13/11/2020 13:55, antispam@math.uni.wroc.pl wrote:
> >>> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> >>>> On 12/11/2020 22:22, antispam@math.uni.wroc.pl wrote:
> >>>>> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> >>>>>> On 12/11/2020 18:56, antispam@math.uni.wroc.pl wrote:
> >>>>>>> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> >>>>
> >>>> Either you have static typing or not. But there is no disagreement. You
> >>>> said you do not know how to implement multiple dispatch (while keeping
> >>>> the language statically typed), I said same thing.
> >>>
> >>> I do not see why failure (error) during dispatch would
> >>> conflict with static typing.
> >>
> >> Because it violates typing. A multiple dispatch method is declared as
> >> acting on the whole Cartesian product of classes of arguments and/or the
> >> result. Violating that is type error. In Ada you cannot declare such
> >> methods ARM 3.9.2 (12).
> > 
> > OK, Ada defines it own terminology, conflicting with terminology
> > used outside Ada.  Since this discussion clearly goes beyond
> > Ada features my assumption was that general terminology applies.
> 
> No, it is not a terminology issue. When an operation is declared it is 
> on all possible values of the arguments, unless explicitly stated otherwise.

Well, in typical multiple dispatch laggage method (operation)
declaration is split into several part.  First part just introduces
name.  Without extra info such method applies to no arguments.
Then there are definitions of specializations, each
specialization has corresponding tuple of types and is
potentially applicable to any combination of derived types.

Language rules explicitely say that operation is applicable if
and only if there is applicable specialization.  Unapplicable
argument combination propagates exception.  Dispatch
rules says which specialization will be run if there are
multiple potentially applicable specializations.  Once you
have all specializations there are no doubt which combinantion
of argument types are valid.

> So if you declare Print acting on the closure of the class rooted in the 
> type Device and the closure of the class rooted in the type Shape, it 
> *must* work on all instances from there.
> 
> If you wanted to limit the set of instances, you must have declared that 
> in some form upfront. That is an elementary language design principle, 
> what you see is what you get. The reader must understand the meaning of 
> a declaration.
> 
> The problem is that this is not possible to do. There is no contract of 
> a multiply-dispatching operation in languages like Julia. Which is why 
> it is a type error or an undefined behavior.

I did not look at Julia rules.  But languages which I know give
tight contract on multiple dispatch.

> >> If you can
> >> detect that the result is incorrect would such detection magically make
> >> it right?
> > 
> > Standard Ada detects overflow instead of returning result.
> > Is Ada wrong?
> 
> The result is returned. Here the result is propagation of Constraint_Error.
> 
> If you contracted the multiple-dispatch operation Print to propagate 
> exception on *certain* combinations of arguments that would not be a 
> fault either. The problem is with [un]certainty.

There is no uncertainty: language rules and program text exactly
specify which argument combinations propagate exception and
which go to specific implementation.

-- 
                              Waldek Hebisch