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.orghttps://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee