[Haskell-cafe] Strange "ambiguity" problems thanks to GADTs

Marco Vassena marco.vax91 at gmail.com
Tue Jul 7 08:42:41 UTC 2015


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 at . 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150707/2d34a4f4/attachment.html>


More information about the Haskell-Cafe mailing list