Suggesting RankNTypes for ill-formed types

Richard Eisenberg rae at
Thu Aug 18 03:04:36 UTC 2016

I tend to agree with Oleg that suggesting `ScopedTypeVariables` may be more helpful to users, even though `ExplicitForAll` is more principled.


> On Aug 11, 2016, at 2:45 PM, Oleg Grenrus <oleg.grenrus at> wrote:
> FWIW. Often when I encounter that error, I want `ScopedTypeVariables`,
> yet my code doesn’t always has the scoped type variable used.
> So even GHC could parse further and propose it to me, there isn’t anything from to do it :(
> I don’t know if many use /just/ `ExplicitForAll`...
> - Oleg
>> On 11 Aug 2016, at 20:30, Karolina Drobnik <karolinadrobnik at <mailto:karolinadrobnik at>> wrote:
>> Hello everyone,
>> I am working on my first ticket (#11669, linked below) 
>> and I have some doubts after a little bit of hacking.
>> There was a hint that an error message should be
>> changed from the one suggesting RankNTypes to ExplicitForall. 
>> In my opinion it would be quite confusing for the user, especially where
>> the type is ill-formed. A plain parse error should be shown here.
>> It is clear that it should be done in such a way after turning on one
>> of the extensions, but what about the situation where proposed
>> fix (suggesting RankNTypes/ExplicitForall) won't work?
>> We should be able to distinguish ill-formed type from the correct one,
>> even before the extension activation. To be honest - I don't know how to do it.
>> Additionally, I am not sure if we can assume that an user wants
>> to use arbitrary rank (which implies ExplicitForall) or just a forall keyword.
>> I am for the second one, but it is just my assumption.
>> And the last minor thing - a type formed in this way also rises an error
>> suggesting using RankNTypes (as we know that wouldn't solve the problem):
>> f :: a. -> Int
>> f = undefined
>> Maybe we could treat it as a typo (simple parse error) and propose
>> an extension activation only when forall was parsed earlier? 
>> That could be tricky.
>> I'd appreciate some thoughts on this issue because I felt a bit lost
>> after digging around the parser.
>> Best regards,
>> Karolina
>> ---------------------------------------------------------
>> #11669 - <>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at <mailto:ghc-devs at>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list