Re: [Haskell-cafe] decoupling type classes

Yin, 2012/1/14 Yin Wang :

On Sat, Jan 14, 2012 at 2:38 PM, Dominique Devriese wrote:

...

...

I may or may not have thought about it. Maybe you can give an example of parametric instances where there could be problems, so that I can figure out whether my system works on the example or not.

The typical example would be

instance Eq a => Eq [a] where  [] == [] = True  (a : as) == (b : bs) = a == b && as == bs  _ == _ = False

It can handle this case, although it doesn't handle it as a parametric instance. I suspect that we don't need the concept of "parameter instances" at all. We just searches for instances recursively at the call site:

That seems like it could work, but typically, one would like termination guarantees for this search, to avoid the type-checker getting stuck...

foo x =   let overload bar (x:Int) = x + 1   in \() -> bar x

baz =  in foo (1::Int)

Even if we have only one definition of "bar" in the program, we should not resolve it to the definition of "bar" inside foo. Because that "bar" is not visible at the call site "foo (1::int)". We should report an error in this case. Think of "bar" as a "typed dynamically scoped variable" helps to justify this decision.

So you're saying that any function that calls an overloaded function should always allow its own callers to provide this, even if a correct instance is in scope. Would that mean all instances have to be resolved from main? This also strikes me as strange, since I gather you would get something like "length :: Monoid Int => [a] -> Int", which would break if you happen to have a multiplicative monoid in scope at the call site? Dominique