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 <[email protected]> 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 <[email protected] >> <mailto:[email protected]>> 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 >> [email protected] <mailto:[email protected]> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
