Alexander Dunlap wrote:
On Sun, Dec 14, 2008 at 8:10 PM, Mario Blažević <mblaze...@stilo.com> wrote:
I'll take a swing at this one:
instance Container (Maybe x) [x] where
wrapper = isNothing
. . .
That isn't a sensible definition of 'wrapper', but I believe without
trying to compile it is completely legal. Which wrapper do you use?
You /don't/ have a different matching Container instance, but without the
functional dependency you /might/, and ghc barfs.
But liftWrap doesn't require any particular instance, it's a
generic function accepting any pair of types for which there is
an instance of Container. Instance selection (as I understand it)
shouldn't come into play until one applies liftWrap to a
particular type, and indeed it does cause problems there: note
the type annotations on the last line. That part I understand
and accept, or at least have learned to live with.
The problem is that y is not mentioned in the signature of wrapper.
When you call wrapper x, there could be many different instances of
Container x y with the same x, so GHC doesn't know which version to
call.
I guess I see it now. However, if the explicit 'Container x y =>'
context couldn't fix the y to use for instantiation of Container x y, I
don't see any way to fix it. And if there is no way to call wrapper in
any context, the class declaration itself is illegal and GHC should have
reported the error much sooner. Should I create a ticket?
You can fix this problem either by adding a functional
dependency or by splitting wrapper out into its own class (Wrapper x,
e.g.) so all of the type variables in the class head are mentioned in
its type and the instance can be determined by the call.
Thanks for asking this question, by the way. I had known about this
issue but had never really realized why it happened. Now that I have
thought about it, I understand it too. :)
Hope that helps,
Alex
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
