[ghc-steering-committee] Visible forall: 3-Year Anniversary

[Alejandro Serrano Mena]

 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 <mail at joachim-breitner.de>
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 at joachim-breitner.de
>  http://www.joachim-breitner.de/
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20211013/2ce6ee80/attachment.html>