[bitc-dev] Moose, rugs, and separate compilation

[Jonathan S. Shapiro]

On Fri, Mar 6, 2009 at 8:07 PM, Sandro Magi <naasking at higherlogics.com> 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.