On Fri, Mar 6, 2009 at 8:07 PM, Sandro Magi <[email protected]> wrote: > Gelf Mrogen wrote: >>>typeclass Foo 'a 'b where >>> testFoo: 'a -> 'b -> bool >> >>>let doFoo: 'b -> bool = >>> fun b -> testFoo 3 b >> >> Answer: No, instance selection should always be done based on the apparent >> types of things, never on the actual types. In this case, if there >> isn't an instance >> for (testFoo Int a) in scope at the time, it's an error. If you want >> otherwise, add a >> typeclass constraint to doFoo.
I seem not to have received a message somewhere in this thread. What is meant here by "apparent type" vs. "actual type"? The policy you describe above is problematic. The problem is that I, as a caller, cannot alter what was in scope at the callee after the fact. This means that it is sometimes impossible for me to introduce new specializations for new types. > So your solution is: at point of type class instantiation, either an > instance is available, or you must push type class resolution back to > the client. In this case: > > let doFoo: 'b -> bool = > fun b -> testFoo 3 b > > becomes > > let doFoo: Foo int 'b => 'b -> bool = > fun b -> testFoo 3 b > > if no instance is available to doFoo. I'm not sure what this means. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
