#460: better migration for non-magical ~
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-no... 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/... 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
Am Freitag, dem 17.12.2021 um 22:38 +0000 schrieb Richard Eisenberg:
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.
This sounds like a well-thought-through refinement, thanks Vlad, and I am happy to follow Richard’s recommendation. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
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
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-no...
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/... 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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
participants (3)
-
Joachim Breitner -
Richard Eisenberg -
Simon Peyton Jones