<html><body><div dir=""><div dir="ltr">
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.</div><div dir="ltr"><br></div><div dir="ltr">I’m also concerned about the migration story:</div><div dir="ltr"><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr">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.</div></blockquote><div dir="ltr"><br></div><div dir="ltr">If we agreed that TypeOperators is almost always on (because of GHC2021), why not simply export this from the Prelude?</div><div dir="ltr"><br></div><div dir="ltr">Regards,</div><div dir="ltr">Alejandro</div><div dir="ltr"><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On 31 Mar 2021 at 16:29:32, Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io">arnaud.spiwack@tweag.io</a>> wrote:<br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div>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).</div><div><br></div><div>The proposal says</div><div><br></div><div>> The compiler internals are simplified, in particular things described in
<code>Note [eqTyCon (~) is built-in syntax]</code>.</div><div><br></div>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.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 31, 2021 at 2:50 AM Richard Eisenberg <<a href="mailto:rae@richarde.dev">rae@richarde.dev</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
I am shepherding proposal #371.<br>
<br>
Proposal: <a href="https://github.com/int-index/ghc-proposals/blob/non-magical-eq/proposals/0000-non-magical-eq.md" rel="noreferrer" target="_blank">https://github.com/int-index/ghc-proposals/blob/non-magical-eq/proposals/0000-non-magical-eq.md</a><br>
Discussion: <a href="https://github.com/ghc-proposals/ghc-proposals/pull/371" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/371</a><br>
<br>
Summary:<br>
<br>
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.<br>
<br>
The motivation for the proposal is uniformity: the goal is to treat (~) just like other type operators.<br>
<br>
Recommendation:<br>
<br>
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.<br>
<br>
What do others think?<br>
<br>
Without dissent, I will mark this proposal as accepted in two weeks.<br>
<br>
Thanks,<br>
Richard<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
<div>
<div>
_______________________________________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a><br><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</div>
</div>
</blockquote>
</div>
</div></div></body></html>