[Haskell-cafe] decoupling type classes

[Dominique Devriese]

Yin,

2012/1/14 Yin Wang <yinwang0 at gmail.com>:
> On Sat, Jan 14, 2012 at 2:38 PM, Dominique Devriese
> <dominique.devriese at cs.kuleuven.be> 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