<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">I disagree that there isn't a truly right answer to this question. IMO the right way to think about type classes is as defining theories: a set of symbols (both types and values) which have certain relationships. The view of type classes as some global relation on types is the wrong one. The only special role of types is in instance selection, and that can and should be a local lexical process. You absolutely should end up with different instances because of different local contexts, for example by picking a different comparison instance before invoking sort. <br><br>I'm not sure I understand your optimization concern. If you write code that's abstract, by making it depend on a number of type classes, then it will tend to be hard to optimize it in a separate-compilation setting. But if in compiling g you
already have concrete types in mind, then the instance used for them should be decided lexically in g and will not be overriden by context later, right? Maybe you can provide an example of what you're worried about here?<br><br><br>--- On <b>Fri, 3/6/09, Jonathan S. Shapiro <i><shap@eros-os.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"><br>From: Jonathan S. Shapiro <shap@eros-os.com><br>Subject: Re: [bitc-dev] Moose, rugs, and separate compilation<br>To: "Discussions about the BitC language" <bitc-dev@coyotos.org><br>Date: Friday, March 6, 2009, 8:11 PM<br><br><div class="plainMail">On Fri, Mar 6, 2009 at 2:54 PM, Sandro Magi <<a ymailto="mailto:naasking@higherlogics.com" href="/mc/compose?to=naasking@higherlogics.com">naasking@higherlogics.com</a>> wrote:<br>>> The question is: which instance should be used in the compilation of<br>>>
g()? That is: which lexical environment should be used to decide what<br>>> instance to use? There is truly no right answer to this.<br>><br>> Let's suppose we're dealing with an Eq 'a type class. Suppose f knows<br>> the concrete type of the list it's dealing with, list char. Suppose that<br>> g does not, and handles list 'a.<br>><br>> I would expect the answer is to transitively use whatever instance f<br>> specifies.. In other words, the beginning of the call chain where the<br>> type class is first required dominates....<br><br>Yes. This was my initial thought as well. This is what I have<br>described as the "lexical instance resolution" policy. And mostly I<br>think that it's the right thing.<br><br>One problem with it is that it makes pre-expanding things for dynamic<br>libraries difficult, because we cannot anticipate the context from<br>which the function will later be called at the time we are compiling<br>the
library.<br><br>Another possible confusion is that you can get situations where one<br>variable 'a is resolved by your caller in one context, and another 'b<br>is resolved in your own context, the two having the same constraint<br>specification but ending up with different instances because of the<br>different lexical contexts.<br><br>Any inspiration on that?<br><br>> I think of type classes as<br>> abstracting vtables, so f is the one building the vtable being passed to<br>> g, so g should be slaved to f.<br><br>Unfortunately that isn't a good model, because the required vtable<br>cannot be build by any single caller. Partly for this reason, I tend<br>to think of this as the caller passing an instance *environment*. The<br>rules for extending that environment as instantiation proceeds are,<br>umm, tricky.<br><br><br>shap<br>_______________________________________________<br>bitc-dev mailing list<br><a ymailto="mailto:bitc-dev@coyotos.org"
href="/mc/compose?to=bitc-dev@coyotos.org">bitc-dev@coyotos.org</a><br><a href="http://www.coyotos.org/mailman/listinfo/bitc-dev" target="_blank">http://www.coyotos.org/mailman/listinfo/bitc-dev</a><br></div></blockquote></td></tr></table><br>