[ghc-steering-committee] #460: better migration for non-magical ~

[Simon Peyton Jones]

I trust Richard (again).  Happy to support this.   Thank you Vlad for this
attention to detail.

Simon

On Fri, 17 Dec 2021 at 22:39, Richard Eisenberg <lists at richarde.dev> wrote:

> Hi all,
>
> I am shepherding Proposal #460, an amendment to accepted proposal #371.
>
> #371 proposed making the ~ operator completely non-magical in parsing,
> behaving syntactically like any other operator. It would have to be
> imported (though it would be exported from the Prelude, so most users get
> it for free), -XTypeOperators would have to be enabled, and its appearance
> is unaffected by -XGADTs or -XTypeFamilies. This proposal was approved, but
> only very weakly: I gave a soft recommendation to accept, which Simon PJ
> trusted (but without much independent confirmation, it seems), Joachim gave
> a weak accept, and Alejandro and Arnaud said things mildly against (but did
> not quite vote for rejection).
>
> Text for accepted proposal #371:
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0371-non-magical-eq.md
>
> This current #460 is a small amendment to #371 that makes the migration
> story gentler. All current programs would continue to be accepted for 8
> releases. If ~ is used in a file without TypeOperators, a warning (enabled
> by default) triggers, saying that the user should enable TypeOperators.
> This fix is backward compatible. If ~ is used when it is out of scope (say,
> because a module does not import the Prelude), a warning (in -Wcompat)
> triggers. The fix is not backward compatible, because (~) is not currently
> exported from the Prelude. This warning gets moved from -Wcompat to the
> default warning set after 2 releases.
>
> The previous migration story had no warning for a missing -XTypeOperators,
> meaning that some code would break immediately (although the fix is easy
> and backward compatible).
>
> Text for amended proposal:
> https://github.com/int-index/ghc-proposals/blob/eqtycon-migration/proposals/0371-non-magical-eq.md
> Amendment diff:
> https://github.com/ghc-proposals/ghc-proposals/pull/460/files
>
> ---
>
> I recommend acceptance, because immediate breakage of code is bad: it
> causes kinks in the update cycle after a GHC release. This new migration
> story should be gentler, and poses little implementation burden.
>
> Given the minor nature of this proposal, I will accept in one week if
> there is not dissent.
>
> Thanks,
> Richard
> _______________________________________________
> 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/20211217/f8309f4b/attachment.html>