Suggesting RankNTypes for ill-formed types
rae at cs.brynmawr.edu
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 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,
>> #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>
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs