Re: feature incompatibilities

["Daniel Yokomiso" <address@hidden>]

----- Original Message -----
From: "Armin Rigo" <arigo@tunes.org>
To: "Daniel Yokomiso" <daniel_yokomiso@softhome.net>
Cc: <ll1-discuss@ai.mit.edu>
Sent: Monday, April 14, 2003 6:10 PM
Subject: Re: feature incompatibilities


> Hello Daniel,
>
> On Sun, Apr 13, 2003 at 09:57:05PM -0300, Daniel Yokomiso wrote:
> >     I know about slate, but I don't think it's type system can solve
this
> > problem. An example will explain this better.
>
> I may be wrong, but what first strikes me as a problem in your example is
the
> definition of methods which are "irrelevant" to the module (in the sense
of
> the Relevant Logic) : the "aMethod(a1, a2 : A)" outside of the module
defining
> A. If you allow this, even in single-dispatch languages, then you
definitely
> run for troubles. But if it is only allowed, in any given module, to
define
> methods whose signature include at least an argument whose class is itself
> defined in the module, then it seems to me that we cannot reproduce the
> ambiguity -- or at least, ambiguity is locally detectable and could be
flagged
> as a module compilation error. (Maybe there is an example that would prove
me
> wrong.)
>
> Of course, whether such a restriction should be imposed or not is an
> interesting question by itself. The original point was that it is possible
for
> a still quite powerful multimethod paradigm to cooperate well with
modules.
>
>
> A bientot,
>
> Armin.

Hi,

    If we impose such restriction I agree this problem won't arise. But
there are other variants that will occurr anyway:


module a {
    class A;
    aMethod(a1, a2 : A) : A;
}
module b {
    import A;
    class B <: A;
    aMethod(a : A, b : B) : B;
}
module c {
    import A;
    class C <: A;
    aMethod(c : C, a : A) : C;
}
module d {
    import A, B, C;
    main {
        a : A := new A;
        b : B := new B;
        c : C := new C;
        aB : A := new B;
        aC : A := new C;

        a1 : A := aMethod(a, a);
        b1 : B := aMethod(a, b);
        c1 : C := aMethod(c, a);

        ?? : A := aMethod(aC, aB);
        ?? : B := aMethod(aC, b);
        ?? : C := aMethod(c, aB);
        ?? : ? := aMethod(c, b);
    }
}


    When I overloaded the methods the restriction was satisfied, and each
module (a,b,c) is correct but can't be used together because using C and B
in the aMethod call is ambiguous. If we drop the restriction module d can
try to solve it, either by subclassing B and C with D and making
aMethod(C,B):D. Note that no rule using a "self" parameter will solve this,
because modules b and c add variants in different positions in the method
signature. Another possible resolution rule (e.g. use the most specialized
version from left to right, or right to left), will break when the call is
dynamic (calls 5 and 6). We can't choose between aMethod(A,B):B and
aMethod(C,A):C without knowing the context, because the covariant return
type is stablished in a static context (call 5 statically returns B, but if
aMethod(C,A):C is invoked it's broken, also for call 6).
    I believe that is possible to have multimethods and modules, but the
type system must be strong enough to solve these mismatches.

    Best regards,
    Daniel Yokomiso.

"All generalizations are false."



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.474 / Virus Database: 272 - Release Date: 18/4/2003