
Hi Wren, I think that the ambiguity comes from the fact that the type variable b is mentioned only in the constraints and in the result type. Crucially the instance B b selected determines the result b, and this in general leads to ambiguity because instances are chosen automatically behind the scenes. A standard way to fix this is to include the ambiguous type b among the types of the arguments. With this trick it is possible to drive the instance choice to select the correct one passing the right argument, avoiding any ambiguity. For example you can use a Proxy b [1], to force the recursive calls to reuse the same b. foo :: (A a, B b) => a i -> Proxy b -> M (b i) foo a p = case view a of ... SomePattern a1 a2 -> do b1 <- foo p a1 b2 <- foo p a2 return . unview $ SomePattern b1 b2 I hope this helps. All the best, Marco [1] https://hackage.haskell.org/package/base-4.7.0.2/docs/Data-Proxy.html On 07/lug/2015, at 02.28, wren romano wrote:
Hi all,
In my latest project I've been using a bunch of GADTs, which unfortunately disables let-polymorphism (i.e., where-polymorphism) in the most annoying way. For the most part I've been able to hack around that limitation via judicious use of ScopedTypeVariables, but I've run into an issue that I can't for the life of me figure out why GHC doesn't like it.
I have something like the following function, where @a@ and @b@ happen to be GADTs:
foo :: (A a, B b) => a i -> M (b i) foo a = case view a of ... SomePattern a1 a2 -> do b1 <- foo a1 b2 <- foo a2 return . unview $ SomePattern b1 b2
It seems to me that the recursive calls should work just fine, using the same @b@ as we'll ultimately be returning. However, for some reason GHC complains about the recursive calls using some other @b0@ can can't deduce @B b0@ from @B b@. Why doesn't GHC unify these two types? How can I force them to unify without adding type annotations at every recursive call?
-- Live well, ~wren _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe