
<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">FWIW. Often when I encounter that error, I want `ScopedTypeVariables`,<div class="">yet my code doesn’t always has the scoped type variable used.</div><div class="">So even GHC could parse further and propose it to me, there isn’t anything from to do it :(</div><div class=""><br class=""></div><div class="">I don’t know if many use /just/ `ExplicitForAll`...</div><div class=""><br class=""></div><div class="">- Oleg</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On 11 Aug 2016, at 20:30, Karolina Drobnik <<a href="mailto:karolinadrobnik@gmail.com" class="">karolinadrobnik@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class="">Hello everyone,<br class=""><br class=""></div>I am working on my first ticket (#11669, linked below) <br class="">and I have some doubts after a little bit of hacking.<br class=""></div><div class=""><br class=""></div><div class="">There was a hint that an error message should be<br class=""></div><div class="">changed from the one suggesting RankNTypes to ExplicitForall. <br class=""></div><div class="">In my opinion it would be quite confusing for the user, especially where<br class=""></div><div class="">the type is ill-formed. A plain parse error should be shown here.<br class=""><br class=""></div><div class="">It is clear that it should be done in such a way after turning on one<br class=""></div><div class="">of the extensions, but what about the situation where proposed<br class="">fix (suggesting RankNTypes/ExplicitForall) won't work?<br class=""></div><div class="">We should be able to distinguish ill-formed type from the correct one,<br class=""></div><div class="">even before the extension activation. To be honest - I don't know how to do it.<br class=""></div><div class=""><br class="">Additionally, I am not sure if we can assume that an user wants<br class=""></div><div class="">to use arbitrary rank (which implies ExplicitForall) or just a forall keyword.<br class="">I am for the second one, but it is just my assumption.<br class=""><br class=""></div><div class="">And the last minor thing - a type formed in this way also rises an error<br class=""></div><div class="">suggesting using RankNTypes (as we know that wouldn't solve the problem):<br class=""></div><div class=""><br class=""></div><div class="">f :: a. -> Int<br class=""></div><div class="">f = undefined<br class=""></div><div class=""><br class=""></div><div class="">Maybe we could treat it as a typo (simple parse error) and propose<br class=""></div><div class="">an extension activation only when forall was parsed earlier? <br class="">That could be tricky.<br class=""><br class=""></div><div class="">I'd appreciate some thoughts on this issue because I felt a bit lost<br class=""></div><div class="">after digging around the parser.<br class=""></div><div class=""><br class=""></div><div class="">Best regards,<br class=""><br class=""></div><div class="">Karolina<br class="">------------------------------<wbr class="">---------------------------<br class="">#11669 - <a href="https://ghc.haskell.org/trac/ghc/ticket/11669" target="_blank" class="">https://ghc.haskell.org/trac/g<wbr class="">hc/ticket/11669</a><br class=""></div></div></div>

_______________________________________________<br class="">ghc-devs mailing list<br class=""><a href="mailto:ghc-devs@haskell.org" class="">ghc-devs@haskell.org</a><br class="">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<br class=""></div></blockquote></div><br class=""></div></body></html>