<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; 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 class="Apple-tab-span" style="white-space:pre"> </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.<br id="lineBreakAtBeginningOfMessage"><div><br></div><div>Chris</div><div><br><blockquote type="cite"><div>On 21 Mar 2024, at 10:11, Simon Peyton Jones <simon.peytonjones@gmail.com> wrote:</div><br class="Apple-interchange-newline"><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:1px solid rgb(204,204,204);padding-left:1ex">
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">malte.ott@maralorn.de</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">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>ghc-steering-committee@haskell.org<br>https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br></div></blockquote></div><br></div></body></html>