2008/12/15 Mario Blazevic <mblaze...@stilo.com>: > 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 >> > >
I think that http://www.haskell.org/pipermail/haskell-cafe/2008-April/041461.html may be relevant. It's a design decision. Alex
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
