Ambiguous type variable ‘f0’ arising from a use of ‘f’

Can anyone explain what happened in GHC 8 such that it forced this change: -data PackMap a b s t = PackMap (Applicative f => (a -> f b) -> s -> f t) +data PackMap a b s t = PackMap (forall f. Applicative f => (a -> f b) -> s -> f t) ... instance PP.SumProfunctor (PackMap a b) where - f +++! g = (PackMap (\x -> eitherFunction (f' x) (g' x))) - where PackMap f' = f - PackMap g' = g + f +++! g = + PackMap (\x -> + case f of + PackMap f' -> + case g of + PackMap g' -> + eitherFunction (f' x) + (g' x)) https://github.com/tomjaguarpaw/haskell-opaleye/pull/140/files The errors are Ambiguous type variable ‘f0’ arising from a use of ‘f’ etc., as seen here https://github.com/tomjaguarpaw/haskell-opaleye/pull/140#issuecomment-198297... Thanks, Tom

GHC 8 does implicit quantification a little differently than previous versions. Previously, writing `=>` in a type meant that GHC looked through the type for free variables and put an implicit `forall` for those variables out front. GHC 8 doesn't do this, explaining the first change. There seems to be no documentation about this (intentional) change; I've filed #11726 requesting documentation.
As for the second change, GHC 7.10 should not have accepted the old program, as it was incorrect. The problem is that GHC must infer types for f' and g'. These types are constrained (they have `Applicative f =>`). They have no type signature, nor are they declared using function syntax. Thus, the monomorphism restriction applies, causing chaos. I bet enabling -XNoMonomorphismRestriction would allow you to undo the second change.
Another common workaround to the monomorphism restriction is to add a type signature. But this doesn't work in the presence of pattern bindings, which is filed as #11339.
I hope this helps!
Richard
On Mar 19, 2016, at 7:03 PM, Tom Ellis
Can anyone explain what happened in GHC 8 such that it forced this change:
-data PackMap a b s t = PackMap (Applicative f => (a -> f b) -> s -> f t) +data PackMap a b s t = PackMap (forall f. Applicative f => (a -> f b) -> s -> f t)
...
instance PP.SumProfunctor (PackMap a b) where - f +++! g = (PackMap (\x -> eitherFunction (f' x) (g' x))) - where PackMap f' = f - PackMap g' = g + f +++! g = + PackMap (\x -> + case f of + PackMap f' -> + case g of + PackMap g' -> + eitherFunction (f' x) + (g' x))
https://github.com/tomjaguarpaw/haskell-opaleye/pull/140/files
The errors are
Ambiguous type variable ‘f0’ arising from a use of ‘f’
etc., as seen here
https://github.com/tomjaguarpaw/haskell-opaleye/pull/140#issuecomment-198297...
Thanks,
Tom _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Hi Richard, thank you very much for the explanations. On Sun, Mar 20, 2016 at 02:47:18PM -0400, Richard Eisenberg wrote:
GHC 8 does implicit quantification a little differently than previous versions. Previously, writing `=>` in a type meant that GHC looked through the type for free variables and put an implicit `forall` for those variables out front. GHC 8 doesn't do this, explaining the first change.
That makes sense, thanks.
As for the second change, GHC 7.10 should not have accepted the old program, as it was incorrect. The problem is that GHC must infer types for f' and g'. These types are constrained (they have `Applicative f =>`). They have no type signature, nor are they declared using function syntax. Thus, the monomorphism restriction applies, causing chaos. I bet enabling -XNoMonomorphismRestriction would allow you to undo the second change.
According to Travis the old program compiled on 7.8 and 7.10. It certainly compiled on 7.6 on my local machine. When was the change that made it break introduced (and what was that change exactly)? Tom

On Mar 20, 2016, at 4:33 PM, Tom Ellis
According to Travis the old program compiled on 7.8 and 7.10. It certainly compiled on 7.6 on my local machine. When was the change that made it break introduced (and what was that change exactly)?
The change was for 8.0, as part of the redesign of part of the typechecker to support TypeApplications. The change in behavior that you're seeing here was not intentional, but was just a side effect of the redesign. It was originally reported as a regression, but I'm pretty sure that your original program should have been rejected, according to my understanding of how the monomorphism restriction works. Richard

On Sun, Mar 20, 2016 at 05:36:42PM -0400, Richard Eisenberg wrote:
On Mar 20, 2016, at 4:33 PM, Tom Ellis
wrote: According to Travis the old program compiled on 7.8 and 7.10. It certainly compiled on 7.6 on my local machine. When was the change that made it break introduced (and what was that change exactly)?
The change was for 8.0, as part of the redesign of part of the typechecker to support TypeApplications. The change in behavior that you're seeing here was not intentional, but was just a side effect of the redesign. It was originally reported as a regression, but I'm pretty sure that your original program should have been rejected, according to my understanding of how the monomorphism restriction works.
Oh, so you're saying it used to work by accident?
participants (2)
-
Richard Eisenberg
-
Tom Ellis