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

[Alejandro Serrano Mena]

 Honestly, I don’t see the benefit of accepting this proposal. It’s clear
that (~) is a special name anyway, because it does not respect the enforced
convention on type constructors (in fact, I’m a bit surprised that you need
to import (~~) and (~#), given their special status), and because the
special role it plays in the language.

I’m also concerned about the migration story:

When the lookup for ~ fails because it is not in scope, assume it refers to
> Data.Type.Equality.~. When this happens and -Wcompat is in effect, emit a
> warning.
>

If we agreed that TypeOperators is almost always on (because of GHC2021),
why not simply export this from the Prelude?

Regards,
Alejandro

On 31 Mar 2021 at 16:29:32, Spiwack, Arnaud <arnaud.spiwack at tweag.io> wrote:

> 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
>>
> _______________________________________________
> 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/20210401/8bfa349b/attachment-0001.html>