[bitc-dev] Moose, rugs, and separate compilation
Jonathan S. Shapiro
shap at eros-os.com
Fri Mar 6 15:11:51 EST 2009
On Fri, Mar 6, 2009 at 2:54 PM, Sandro Magi <naasking at higherlogics.com> wrote:
>> The question is: which instance should be used in the compilation of
>> g()? That is: which lexical environment should be used to decide what
>> instance to use? There is truly no right answer to this.
> Let's suppose we're dealing with an Eq 'a type class. Suppose f knows
> the concrete type of the list it's dealing with, list char. Suppose that
> g does not, and handles list 'a.
> I would expect the answer is to transitively use whatever instance f
> specifies. In other words, the beginning of the call chain where the
> type class is first required dominates....
Yes. This was my initial thought as well. This is what I have
described as the "lexical instance resolution" policy. And mostly I
think that it's the right thing.
One problem with it is that it makes pre-expanding things for dynamic
libraries difficult, because we cannot anticipate the context from
which the function will later be called at the time we are compiling
Another possible confusion is that you can get situations where one
variable 'a is resolved by your caller in one context, and another 'b
is resolved in your own context, the two having the same constraint
specification but ending up with different instances because of the
different lexical contexts.
Any inspiration on that?
> I think of type classes as
> abstracting vtables, so f is the one building the vtable being passed to
> g, so g should be slaved to f.
Unfortunately that isn't a good model, because the required vtable
cannot be build by any single caller. Partly for this reason, I tend
to think of this as the caller passing an instance *environment*. The
rules for extending that environment as instantiation proceeds are,
More information about the bitc-dev