<div dir="auto">I’m in favor of the proposal:</div><div dir="auto"><br></div><div dir="auto">For </div><div dir="auto"><br></div><div dir="auto">a `m` b -> (a,b)</div><div dir="auto"><br></div><div dir="auto">I think it’s debatable, “forall a m b” vs “forall m a b”</div><div dir="auto"><br></div><div dir="auto">But what about more nested expressions? If we had</div><div dir="auto"><br></div><div dir="auto">(a `m` b) `n` (c `o` d) -> (a,b,c,d),</div><div dir="auto"><br></div><div dir="auto">The current order would give “forall n m a b o c d”, whereas the change would give “forall a m b n c o d”. The latter is “less surprising”, and I’m in favor of the element of least surprise. Same with linear multiplicities, I was surprised to see the m being last in “a %m -> b”.</div><div dir="auto"><br></div><div dir="auto">As mentioned before, this seems unlikely to cause breakage in the wild, and the fix is a simple explicit forall. So I’m in favor of the bug fix.<br><br clear="all"><div dir="auto"><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">/Matti Palli</div></div></div><div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 21, 2024 at 11:46 Chris Dornan <<a href="mailto:chris@chrisdornan.com">chris@chrisdornan.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div style="line-break:after-white-space">I can go either way. We should make the linear change of course. Both Simon and Adam make good arguments for accepting and rejecting the infix operator aspect.<div><br></div><div>I would probably be tempted to stick with the status quo but am happy<span style="white-space:pre-wrap"> </span>to accept the whole proposal — as that requires no further change I am coming down on that side — to accept the whole proposal unless someone objects.</div></div><div style="line-break:after-white-space"><div><br id="m_8075200391287462349lineBreakAtBeginningOfMessage"><div><br></div><div>Chris</div><div><br><blockquote type="cite"><div>On 21 Mar 2024, at 10:11, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Great summary. <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><blockquote class="gmail_default gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">
I am generally not a fan of enshrining historic coincidence in the language when<br>
the cost of fixing it is bareable. On the other hand this is such a minor detail<br>
that I don’t think it will matter much in either direction. <br></blockquote><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">That's exactly why I am on the fence!</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Chris, Simon M, Matthias, any opinions?</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">We may just have to vote, as Malte says</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 20 Mar 2024 at 23:42, Malte Ott <<a href="mailto:malte.ott@maralorn.de" target="_blank">malte.ott@maralorn.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Okay, let me summarize the voiced opinions:<br>
<br>
We have agreement on the change to multiplicities.<br>
<br>
On the infix type operator we are a bit stuck:<br>
<br>
* Richard, Eric and I are in favor of fixing the bug.<br>
* Adam and Arnaud are in favor of staying stable, living with the exception<br>
* Simon was on the fix side but switched to undecided, waiting for more opinions<br>
* Moritz preferred staying stable, but deferred to Simon before his switch<br>
<br>
Overall slightly more votes for the change but subjectively hold less strongly<br>
than the opinions against it.<br>
<br>
Since I am unclear on how to proceed I’d love to hear more opinions (especially<br>
of committee members who haven’t voiced theirs about this proposal).<br>
<br>
I am generally not a fan of enshrining historic coincidence in the language when<br>
the cost of fixing it is bareable. On the other hand this is such a minor detail<br>
that I don’t think it will matter much in either direction.<br>
<br>
If we cannot come to a consensus soon I will put it a to a vote. We<br>
shouldn’t spend too much time on this.<br>
<br>
Best<br>
Malte<br>
<br>
On 2024-03-19 15:12, Arnaud Spiwack wrote:<br>
> On Tue, 19 Mar 2024 at 10:26, Simon Peyton Jones <<br>
> <a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>> wrote:<br>
> <br>
> > But I think you are now saying that *even if a left-to-right order was<br>
> > "best", *there is a long-standing bug in GHC that puts `b` first in (a<br>
> > `b` c`), and it's not worth the risk of change.   So instead we should<br>
> > institutionalise the bug into the spec.<br>
> ><br>
> <br>
> This is, at least, my position. This is a bug fix, but the bug is so tiny,<br>
> that even if the breakage is rare, it's not necessarily worth it, and it<br>
> may be better to bake the exception into the spec. I'm weakly on the side<br>
> that baking the exception is better.<br>
<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>
<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>
_______________________________________________<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" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br></div></blockquote></div><br></div></div>_______________________________________________<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>