[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: feature incompatibilities

----- 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
> > problem. An example will explain this better.
> I may be wrong, but what first strikes me as a problem in your example is
> definition of methods which are "irrelevant" to the module (in the sense
> the Relevant Logic) : the "aMethod(a1, a2 : A)" outside of the module
> A. If you allow this, even in single-dispatch languages, then you
> run for troubles. But if it is only allowed, in any given module, to
> 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
> as a module compilation error. (Maybe there is an example that would prove
> 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
> a still quite powerful multimethod paradigm to cooperate well with
> A bientot,
> Armin.


    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