<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">I'm in favour of accepting as-is  -- that is, use left to right always.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">It's encouraging that there was no breakage when compiling 3,337 packages.</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><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 7 Apr 2024 at 22:37, 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">Dear all,<br>
<br>
I left this lingering for a bit in the hope a consensus might magically appear,<br>
alas it didn’t.<br>
<br>
We have consensus on accepting the proposal for the multiplicity annotations. <br>
<br>
For infix type operators I am now trying to convert previously voiced opinions<br>
as faithfully as possible into votes:<br>
<br>
Pro:<br>
<br>
Eric, Malte, Chris, Matti<br>
<br>
Con:<br>
<br>
Adam, Arnaud<br>
<br>
Undecided:<br>
<br>
Simon PJ, Moritz, Simon M<br>
<br>
Thus, as it stands we will accept the proposal as is, but it is close.<br>
Please voice your opinion if you want to change your vote until Friday, I will<br>
call the vote on the weekend.<br>
<br>
Best<br>
Malte<br>
<br>
On 2024-03-21 17:46, Matthías Páll Gissurarson wrote:<br>
> I’m in favor of the proposal:<br>
> <br>
> For<br>
> <br>
> a `m` b -> (a,b)<br>
> <br>
> I think it’s debatable, “forall a m b” vs “forall m a b”<br>
> <br>
> But what about more nested expressions? If we had<br>
> <br>
> (a `m` b) `n` (c `o` d) -> (a,b,c,d),<br>
> <br>
> The current order would give “forall n m a b o c d”, whereas the change<br>
> would give “forall a m b n c o d”. The latter is “less surprising”, and I’m<br>
> in favor of the element of least surprise. Same with linear multiplicities,<br>
> I was surprised to see the m being last in “a %m -> b”.<br>
> <br>
> As mentioned before, this seems unlikely to cause breakage in the wild, and<br>
> the fix is a simple explicit forall. So I’m in favor of the bug fix.<br>
> <br>
> /Matti Palli<br>
> <br>
> <br>
> On Thu, Mar 21, 2024 at 11:46 Chris Dornan <<a href="mailto:chris@chrisdornan.com" target="_blank">chris@chrisdornan.com</a>> wrote:<br>
> <br>
> > I can go either way. We should make the linear change of course. Both<br>
> > Simon and Adam make good arguments for accepting and rejecting the infix<br>
> > operator aspect.<br>
> ><br>
> > I would probably be tempted to stick with the status quo but am happy to<br>
> > accept the whole proposal — as that requires no further change I am coming<br>
> > down on that side — to accept the whole proposal unless someone objects.<br>
> ><br>
> ><br>
> > Chris<br>
> ><br>
> > On 21 Mar 2024, at 10:11, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>><br>
> > wrote:<br>
> ><br>
> > Great summary.<br>
> ><br>
> > I am generally not a fan of enshrining historic coincidence in the<br>
> > language when<br>
> > the cost of fixing it is bareable. On the other hand this is such a minor<br>
> > detail<br>
> > that I don’t think it will matter much in either direction.<br>
> ><br>
> ><br>
> > That's exactly why I am on the fence!<br>
> ><br>
> > Chris, Simon M, Matthias, any opinions?<br>
> ><br>
> > We may just have to vote, as Malte says<br>
> ><br>
> > Simon<br>
> ><br>
> ><br>
> > 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>
> ><br>
> >> 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<br>
> >> exception<br>
> >> * Simon was on the fix side but switched to undecided, waiting for more<br>
> >> 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<br>
> >> strongly<br>
> >> than the opinions against it.<br>
> >><br>
> >> Since I am unclear on how to proceed I’d love to hear more opinions<br>
> >> (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<br>
> >> language when<br>
> >> the cost of fixing it is bareable. On the other hand this is such a minor<br>
> >> 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<br>
> >> 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<br>
> >> 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>
> >> ><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>
> >><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>
> > _______________________________________________<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>
> _______________________________________________<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>