Suggesting RankNTypes for ill-formed types

[Richard Eisenberg]

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

Richard

> On Aug 11, 2016, at 2:45 PM, Oleg Grenrus <oleg.grenrus at iki.fi> 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 gmail.com <mailto:karolinadrobnik at gmail.com>> 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 - https://ghc.haskell.org/trac/ghc/ticket/11669 <https://ghc.haskell.org/trac/ghc/ticket/11669>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160817/71801cf6/attachment.html>