<div dir="ltr"><div><div><div>Hello everyone,<br><br></div>I am working on my first ticket (#11669, linked below) <br>and I have some doubts after a little bit of hacking.<br></div><div><br></div><div>There was a hint that an error message should be<br></div><div>changed from the one suggesting RankNTypes to ExplicitForall. <br></div><div>In my opinion it would be quite confusing for the user, especially where<br></div><div>the type is ill-formed. A plain parse error should be shown here.<br><br></div><div>It is clear that it should be done in such a way after turning on one<br></div><div>of the extensions, but what about the situation where proposed<br>fix (suggesting RankNTypes/ExplicitForall) won't work?<br></div><div>We should be able to distinguish ill-formed type from the correct one,<br></div><div>even before the extension activation. To be honest - I don't know how to do it.<br></div><div><br>Additionally, I am not sure if we can assume that an user wants<br></div><div>to use arbitrary rank (which implies ExplicitForall) or just a forall keyword.<br>I am for the second one, but it is just my assumption.<br><br></div><div>And the last minor thing - a type formed in this way also rises an error<br></div><div>suggesting using RankNTypes (as we know that wouldn't solve the problem):<br></div><div><br></div><div>f :: a. -> Int<br></div><div>f = undefined<br></div><div><br></div><div>Maybe we could treat it as a typo (simple parse error) and propose<br></div><div>an extension activation only when forall was parsed earlier? <br>That could be tricky.<br><br></div><div>I'd appreciate some thoughts on this issue because I felt a bit lost<br></div><div>after digging around the parser.<br></div><div><br></div><div>Best regards,<br><br></div><div>Karolina<br>------------------------------<wbr>---------------------------<br>#11669 - <a href="https://ghc.haskell.org/trac/ghc/ticket/11669" target="_blank">https://ghc.haskell.org/trac/g<wbr>hc/ticket/11669</a><br></div></div></div>