[ghc-steering-committee] #371: Stop treating ~ magically. Rec: weak accept

[Spiwack, Arnaud]

This looks very minor. I'm not convinced that it is worth the hassle (that
being said, it is not hard to write code that is both forward and backward
compatible, so maybe there won't be much headache).

The proposal says

> The compiler internals are simplified, in particular things described in Note
[eqTyCon (~) is built-in syntax].

That's the really appetizing part (the fact that `~` will have a Haddock
documentation is not bad either). Those of us who have been involved in the
parts of the compiler that are touched here: do you think this is a
worthwhile simplification? That would secure my vote.

On Wed, Mar 31, 2021 at 2:50 AM Richard Eisenberg <rae at richarde.dev> wrote:

> Hi all,
>
> I am shepherding proposal #371.
>
> Proposal:
> https://github.com/int-index/ghc-proposals/blob/non-magical-eq/proposals/0000-non-magical-eq.md
> Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/371
>
> Summary:
>
> Currently, the type equality operator (~) is always in scope, but you can
> use it only if -XGADTs or -XTypeFamilies is enabled. The proposal instead
> changes this arrangement to export (~) from Data.Type.Equality (an existing
> module in `base`), and requiring -XTypeOperators to use it (as we do for
> all other infix operators in types). There is an 8-release migration plan,
> where for 6 releases, all uses of (~) that do not import it from
> Data.Type.Equality will get a warning telling the user to import
> Data.Type.Equality.
>
> The motivation for the proposal is uniformity: the goal is to treat (~)
> just like other type operators.
>
> Recommendation:
>
> I'm very much on the fence on this one, but in the end fall into the
> "accept" camp. The goal here is to achieve a simple cleanup in the language
> design (and implementation). It's a worthy goal, but it's disruptive.
> However, I think the disruption is small enough that it motivates the
> change. The fix for affected users is quite quick, and large-scale Haskell
> users probably already have a custom prelude that could make the change
> even easier to accommodate. Note also that TypeOperators is part of
> GHC2021, and so the change will likely only be a new import.
>
> What do others think?
>
> Without dissent, I will mark this proposal as accepted in two weeks.
>
> 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/20210331/eb0ef689/attachment.html>