On Mon, Dec 29, 2014 at 12:13 AM, Jonathan S. Shapiro <[email protected]>
wrote:
> Because of the instance resolution and instance coherence issues that
> plague type classes, it's clear that the BitC approach to type classes
> needs to evolve away from Haskell a bit. BitC needs to pay more attention
> to module import hygiene. At the very least, this means that *importing* a
> type class instance and opening it into the current instance resolution
> environment need to be different operations. It also means that instance
> resolution needs to be performed w.r.t. an explicitly manipulable instance
> environment. We're going to have to break some new ground here.
>
Have you considered performing environment resolution via something like
class parametric-instantiation?
I have been noodling a thought down this path, which I think of as
parametricly-instantiated static-mixins. It's probably easiest to be clear
by way of an example.
Pretty much any language can host an Adaptor instance, such as the
following, in C#:
interface AddableAdaptor<T> {
> T add(T a, T b);
> }
> class intAdder : AddableAdaptor<int> {
> int add(int a, int b);
> }
> class Accumulator<T> {
> T cur;
> AddableAdaptor<T> adder;
> Accumulator(T initial, AddableAdaptor<T> adder) {
> this.adder= adder;
> this.cur = initial;
> }
> void accumulate(T value) { cur = adder.add(cur,value); }
> }
> var myAccumulator = new Accumulator<int>(4, new intAdder());
> myAccumulator.accumulate(6);
However, there is no reason for the above adaptor to be an instance. It has
no instance state. What I want, is a static-mixin-implementation which is
bound by parametric-instantiation. Expressed in psudo-syntax:
static interface this<T> Addable {
> T add(this T, T);
> }
> static mixin this<int> IntAccumulator {
> int add(this int, int value) {
> return this+value;
> }
> }
> class Accumulator<T> mixin adder:Addable<T> {
> public T current;
> Accumulator(T initial) { current = initial; }
> void accumulate(T value) { current = current.add(value); }
> }
>
> var myAccumulator = new Accumulator<int, adder:IntAccumulator>(4);
> myAccumulator.accumulate(6);
By inferring the appropriate from the environment, the cognitive load of
providing them could be eliminated in most cases. However, they could still
be overridden when necessary. Because the binding happens statically at the
parametric-instantiation, it's more powerful than it happening lexically at
the call site, yet as far as I can see, it still removes any ambiguity WRT
modules and late-binding.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
