2008/12/15 Mario Blazevic

Alexander Dunlap wrote:

...

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?

Please do not create a ticket. Such a typeclass is legitimate, but not useful alone or with functional dependencies. It is useful with Type Families though, so celebrate! Thomas ----- START CODE ---- {-# LANGUAGE TypeFamilies, MultiParamTypeClasses, FlexibleInstances #-} import Data.Maybe class Container x where type Contains x wrapper :: x -> Bool unwrap :: x -> Contains x rewrap :: Contains x -> x liftWrap :: Container x => (Contains x -> Contains x) -> x -> x liftWrap f x = (if wrapper x then rewrap . f . unwrap else id) x instance Container (Maybe x) where type Contains (Maybe x) = x wrapper = isJust unwrap = fromJust rewrap = Just main = print (liftWrap (succ :: Int -> Int) (Just 1 :: Maybe Int)) -----

2008/12/15 Mario Blazevic :

Alexander Dunlap wrote:

...

On Sun, Dec 14, 2008 at 8:10 PM, Mario Blažević 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