Yin, 2012/1/14 Yin Wang <yinwa...@gmail.com>: > On Sat, Jan 14, 2012 at 2:38 PM, Dominique Devriese > <dominique.devri...@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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
