<html><body><div dir="ltr">
Hi,</div><div dir="ltr"><br></div><div dir="ltr">As a general rule, I would prefer *not* introducing breaking changes. People already complain how much breakage is in the Haskell ecosystem in general, and we should try not to be part of the problem too.</div><div dir="ltr"><br></div><div dir="ltr">Alejandro<br><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">El 13 oct 2021 13:16:39, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> escribió:<br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>
Hi,<br><br>thanks for pushing us here again. Fundamentally in favor.<br><br>For those of you who are not following Github, Vlad and I are<br>disagreeing over how breaking the change can be. The proposal as it<br>stands makes forall a keyword in terms – irrespective of any extensions<br>that are on.<br><br>Vlad argues that this is good: Code that uses forall as an identifier<br>should change that as soon as possible. Also, it simplifies the<br>implementation of the lexer and parser if the keywordhood of `forall`<br>doesn't depend on extensions.<br><br>I argue that this is too inconsiderate towards our users. While I am<br>generally not hesitant to require _code changes_, possibly even with<br>CPP, when people enable new extensions, or sometimes even when<br>upgrading the compiler, this case seems to be qualitatively more<br>severe: Library who _export_ an identifier called `forall` (which a few<br>“real world” libraries do; HaTeX, sbv, what4 and many others) would<br>find themselves unable to support a newer compiler without a _breaking_<br>change to their public API. I find that quite a big hammer, and I am<br>not sure if we had precedent for that before, nor that we want to set<br>that precedent.<br><br>And it seems possible to have a milder migration strategy: <br> * Introduce -XForallInTerms<br> * It’s implied by new extensions like -XRequiredTypeArguments<br> * It becomes the default with next GHC20xx (but not with Haskell2021)<br> * -XNoForallInTerm (and the kludges necessary to support that) stay <br> around for a while<br>(NB: One can _use_ qualified names that happen to be keywords just<br>fine; if a module M exports class, M.class works. So users of such old<br>APIs can use HaTeX.forall even if they have opted into the new world.)<br><br>I think we’ve exchanged the arguments, so now it remains a judgement<br>call between more nudging, simpler GHC and a less complex set of<br>extensions on the one hand vs. not forcing developers to break their<br>library APIs in order to use new GHC versions.<br><br>What do the others think?<br><br>Cheers,<br>Joachim <br><br><br><br><br>-- <br>Joachim Breitner<br> <a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a><br> <a href="http://www.joachim-breitner.de/">http://www.joachim-breitner.de/</a><br><br><br>_______________________________________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a><br><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</div>
</div>
</blockquote>
</div>
</div></body></html>