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