[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@softhome.net>
Cc: <ll1-discuss@ai.mit.edu>
Sent: Saturday, April 12, 2003 1:54 PM
Subject: Re: feature incompatibilities


> > Another possible incompatibility lies in multi-methods
> > vs. "independent" modules. As multi-methods live in a global
> > namespace, clashes are inevitable, so two "correct" modules compiled
> > separated may give ambiguity errors when used together.
>
> There is an experimental language that works around this problem. See
> http://slate.tunes.org.
>
>
> Armin

Hi,

    I know about slate, but I don't think it's type system can solve this
problem. An example will explain this better.

module one

    class A;
}

module two {
    import one;
    class C <: A;
    aMethod(a1, a2 : A) : A;
    aMethod(c1, c2 : C) : C;
}

module three

    import one;
    class B <: A;
    class D <: B;
    aMethod(a1, a2 : A) : B;
    aMethod(d1, d2 : D) : D;
}

module four {
    import one, two, three;
    main() {
    }
}


    The method "aMethod" is defined in modules two and three with
incompatible signatures. Alone each is correct, but when used together they
give ambiguous definitions. Module four can decide to ignore one ot the
definitions, because other methods defined in two or three may call these
features as they are defined. This method has different semantics in two and
three, but because it's a multi-method it must have a common root when four
tries to use it. It's a problem inerent to multi-methods, regarding
multiple, incompatible definitions. I have a possible solution in my
language, eon, but I have to verify the soundness of its type system. My
idea is to allow module "subtyping", so one can write something like this:

module hack {
// generic multimethod
    aMethod[a](h1, h2 : A): a;
    module two' <: two {
// overrides the versions from two
        aMethod[A](a1, a2 : A) : A;
        aMethod[A](c1, c2 : C) : C;
    }
    module three' <: three {
// overrides the versions from three
        aMethod[B](a1, a2 : A) : B;
        aMethod[B](d1, d2 : D) : D;
    }
}
module four {
    import one, hack.two', three';
    main() {
    }
}


    With this solution we create sub-modules for both two and three, include
a inheritance from a generic class and make aMethod a generic method,
allowing multiple versions of it (because aMethod[A] is different from
aMethod[B]) and all the calls in module two' and three can be made with an
implicit type parameter (pure syntatic sugar), but module four must
disambiguate them. I think multi-methods are they way to go, but they have
their share of problems.

    Best regards,
    Daniel Yokomiso.

"But what do you expect? Truth is not an industrial product."
 - Wlad Turski, as quoted by Edsger W. Dijkstra (EWD714)


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