Prev: Can you suggest a project?
Next: Modularity problems with multiple dispatch (was: Scala and problems with OOP)
From: Joachim Durchholz on 22 Nov 2007 04:22
S Perryman schrieb:
> AFAIK, there are prog langs with type checking that ensure for multiple
> dispatch, appropriate impls exist for those f/A/B instances in code that
> are in separate modules (I think Isaac Gouy posted an example to
> comp.object a couple of years ago) . I cannot recall whether the check
> was static, or (as is usual) deferred to runtime.

I read a paper on the topic, possibly one by Isaac himself.

IIRC, the check was static. The paper mostly demonstrated that such a
check was possible, and detailed algorithms to do so.
At least for me, the paper held no surprises: the algorithms were really
straightforward.

> The difficulty will be for systems supporting concepts such as "separate
> compilation" (like Ada etc) .

It's not *that* outlandish. Essentially, the check would have to be
postponed to the phase where the whole-system optimizations are done. In
a system that makes liberal use of dynamic dispatch, having such a
global optimization phase is a good idea anyway.

>> CLOS supports multiple dispatch, but I can't imagine how the programmer
>> can possibly know which methods happen at run time, and in which order,
>> when you do the equivalent of "f (A', B')".
>
> Std CLOS is left-to-right evaluation. The most basic scheme would be :
>
> Find all appropriate f based on A' (L1) , using the CLOS precedence
> rules for inheritance etc. Do the same for B' , based on L1.
> You will have a candidate f, or not (error) .

Yes, but it will sometimes not be the right one.
Worse, if you combine libraries that implement A' and B', and you have a
multiple-dispatching function f(A,B), you need but don't have f(A',B'),
and you won't even be notified of the problem, you'll just get an
obscure bug.

Regards,
Jo
From: S Perryman on 22 Nov 2007 05:51
Joachim Durchholz wrote:

> S Perryman schrieb:

>> AFAIK, there are prog langs with type checking that ensure for multiple
>> dispatch, appropriate impls exist for those f/A/B instances in code that
>> are in separate modules (I think Isaac Gouy posted an example to
>> comp.object a couple of years ago) . I cannot recall whether the check
>> was static, or (as is usual) deferred to runtime.

> I read a paper on the topic, possibly one by Isaac himself.

> IIRC, the check was static. The paper mostly demonstrated that such a
> check was possible, and detailed algorithms to do so.

I would have to do a more precise Usenet search to get the exact info
(hence not stating anything other than the vague info I mentioned) .


> At least for me, the paper held no surprises: the algorithms were really
> straightforward.

Should be, on the basis that all relevant information is to hand ...


>> The difficulty will be for systems supporting concepts such as "separate
>> compilation" (like Ada etc) .

> It's not *that* outlandish. Essentially, the check would have to be
> postponed to the phase where the whole-system optimizations are done. In
> a system that makes liberal use of dynamic dispatch, having such a
> global optimization phase is a good idea anyway.

For prog langs such as Ada, "all relevant information is to hand" might
be link-time (assuming no dynamic library linkage/resolution etc) . Perhaps
not as early as desired, but no runtime dangers (an executable image will
not be created etc) .


RD> CLOS supports multiple dispatch, but I can't imagine how the programmer
RD> can possibly know which methods happen at run time, and in which order,
RD> when you do the equivalent of "f (A', B')".

>> Std CLOS is left-to-right evaluation. The most basic scheme would be :

>> Find all appropriate f based on A' (L1) , using the CLOS precedence
>> rules for inheritance etc. Do the same for B' , based on L1.
>> You will have a candidate f, or not (error) .

> Yes, but it will sometimes not be the right one.

Again, uncertainty (wrt what CLOS can do) . The MOP info in the Sonya Keene
book that I have (c1990) suggests the MOP can tell me the most specific
method (the defgeneric for which class etc) that would be invoked for a
given class instance. But the book did not suggest that the MOP (at that
time) would give similar info if/when given the types of the input/output
parameters (ie execute the multiple dispatch to select the method impl) .

If a sys/env supports multiple dispatch, the means for a user to determine
which op will be invoked, is very important.


> Worse, if you combine libraries that implement A' and B', and you have a
> multiple-dispatching function f(A,B), you need but don't have f(A',B'),
> and you won't even be notified of the problem, you'll just get an
> obscure bug.

Indeed.
Not being able to deduce what is being invoked is much worse than
failing due to nothing being invoked.


Regards,
Steven Perryman
First  |  Prev  | 
Pages: 1 2 3
Prev: Can you suggest a project?
Next: Modularity problems with multiple dispatch (was: Scala and problems with OOP)