Hi, 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. Alejandro El 13 oct 2021 13:16:39, Joachim Breitner escribió:

Hi,

thanks for pushing us here again. Fundamentally in favor.

For those of you who are not following Github, Vlad and I are disagreeing over how breaking the change can be. The proposal as it stands makes forall a keyword in terms – irrespective of any extensions that are on.

Vlad argues that this is good: Code that uses forall as an identifier should change that as soon as possible. Also, it simplifies the implementation of the lexer and parser if the keywordhood of `forall` doesn't depend on extensions.

I argue that this is too inconsiderate towards our users. While I am generally not hesitant to require _code changes_, possibly even with CPP, when people enable new extensions, or sometimes even when upgrading the compiler, this case seems to be qualitatively more severe: Library who _export_ an identifier called `forall` (which a few “real world” libraries do; HaTeX, sbv, what4 and many others) would find themselves unable to support a newer compiler without a _breaking_ change to their public API. I find that quite a big hammer, and I am not sure if we had precedent for that before, nor that we want to set that precedent.

And it seems possible to have a milder migration strategy: * Introduce -XForallInTerms * It’s implied by new extensions like -XRequiredTypeArguments * It becomes the default with next GHC20xx (but not with Haskell2021) * -XNoForallInTerm (and the kludges necessary to support that) stay around for a while (NB: One can _use_ qualified names that happen to be keywords just fine; if a module M exports class, M.class works. So users of such old APIs can use HaTeX.forall even if they have opted into the new world.)

I think we’ve exchanged the arguments, so now it remains a judgement call between more nudging, simpler GHC and a less complex set of extensions on the one hand vs. not forcing developers to break their library APIs in order to use new GHC versions.

What do the others think?

Cheers, Joachim

-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee