[ghc-steering-committee] Please review #640: Fix quantification order for a `op` b and a %m -> b (Recommendation: Accept)

[Malte Ott]

The vote is clear enough then and I have accepted the proposal. Thanks for the
discussion!

Best
Malte

On 2024-04-08 17:31, Simon Peyton Jones wrote:
> I'm in favour of accepting as-is  -- that is, use left to right always.
> 
> It's encouraging that there was no breakage when compiling 3,337 packages.
> 
> Simon
> 
> On Sun, 7 Apr 2024 at 22:37, Malte Ott <malte.ott at maralorn.de> wrote:
> 
> > Dear all,
> >
> > I left this lingering for a bit in the hope a consensus might magically
> > appear,
> > alas it didn’t.
> >
> > We have consensus on accepting the proposal for the multiplicity
> > annotations.
> >
> > For infix type operators I am now trying to convert previously voiced
> > opinions
> > as faithfully as possible into votes:
> >
> > Pro:
> >
> > Eric, Malte, Chris, Matti
> >
> > Con:
> >
> > Adam, Arnaud
> >
> > Undecided:
> >
> > Simon PJ, Moritz, Simon M
> >
> > Thus, as it stands we will accept the proposal as is, but it is close.
> > Please voice your opinion if you want to change your vote until Friday, I
> > will
> > call the vote on the weekend.
> >
> > Best
> > Malte
> >
> > On 2024-03-21 17:46, Matthías Páll Gissurarson wrote:
> > > I’m in favor of the proposal:
> > >
> > > For
> > >
> > > a `m` b -> (a,b)
> > >
> > > I think it’s debatable, “forall a m b” vs “forall m a b”
> > >
> > > But what about more nested expressions? If we had
> > >
> > > (a `m` b) `n` (c `o` d) -> (a,b,c,d),
> > >
> > > 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”.
> > >
> > > 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.
> > >
> > > /Matti Palli
> > >
> > >
> > > On Thu, Mar 21, 2024 at 11:46 Chris Dornan <chris at chrisdornan.com>
> > wrote:
> > >
> > > > 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.
> > > >
> > > > I would probably be tempted to stick with the status quo but am happy
> > 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.
> > > >
> > > >
> > > > Chris
> > > >
> > > > On 21 Mar 2024, at 10:11, Simon Peyton Jones <
> > simon.peytonjones at gmail.com>
> > > > wrote:
> > > >
> > > > Great summary.
> > > >
> > > > I am generally not a fan of enshrining historic coincidence in the
> > > > language when
> > > > the cost of fixing it is bareable. On the other hand this is such a
> > minor
> > > > detail
> > > > that I don’t think it will matter much in either direction.
> > > >
> > > >
> > > > That's exactly why I am on the fence!
> > > >
> > > > Chris, Simon M, Matthias, any opinions?
> > > >
> > > > We may just have to vote, as Malte says
> > > >
> > > > Simon
> > > >
> > > >
> > > > On Wed, 20 Mar 2024 at 23:42, Malte Ott <malte.ott at maralorn.de> wrote:
> > > >
> > > >> Okay, let me summarize the voiced opinions:
> > > >>
> > > >> We have agreement on the change to multiplicities.
> > > >>
> > > >> On the infix type operator we are a bit stuck:
> > > >>
> > > >> * Richard, Eric and I are in favor of fixing the bug.
> > > >> * Adam and Arnaud are in favor of staying stable, living with the
> > > >> exception
> > > >> * Simon was on the fix side but switched to undecided, waiting for
> > more
> > > >> opinions
> > > >> * Moritz preferred staying stable, but deferred to Simon before his
> > switch
> > > >>
> > > >> Overall slightly more votes for the change but subjectively hold less
> > > >> strongly
> > > >> than the opinions against it.
> > > >>
> > > >> Since I am unclear on how to proceed I’d love to hear more opinions
> > > >> (especially
> > > >> of committee members who haven’t voiced theirs about this proposal).
> > > >>
> > > >> I am generally not a fan of enshrining historic coincidence in the
> > > >> language when
> > > >> the cost of fixing it is bareable. On the other hand this is such a
> > minor
> > > >> detail
> > > >> that I don’t think it will matter much in either direction.
> > > >>
> > > >> If we cannot come to a consensus soon I will put it a to a vote. We
> > > >> shouldn’t spend too much time on this.
> > > >>
> > > >> Best
> > > >> Malte
> > > >>
> > > >> On 2024-03-19 15:12, Arnaud Spiwack wrote:
> > > >> > On Tue, 19 Mar 2024 at 10:26, Simon Peyton Jones <
> > > >> > simon.peytonjones at gmail.com> wrote:
> > > >> >
> > > >> > > But I think you are now saying that *even if a left-to-right
> > order was
> > > >> > > "best", *there is a long-standing bug in GHC that puts `b` first
> > in (a
> > > >> > > `b` c`), and it's not worth the risk of change.   So instead we
> > should
> > > >> > > institutionalise the bug into the spec.
> > > >> > >
> > > >> >
> > > >> > This is, at least, my position. This is a bug fix, but the bug is so
> > > >> tiny,
> > > >> > that even if the breakage is rare, it's not necessarily worth it,
> > and it
> > > >> > may be better to bake the exception into the spec. I'm weakly on the
> > > >> side
> > > >> > that baking the exception is better.
> > > >>
> > > >> > _______________________________________________
> > > >> > 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
> > > >>
> > > > _______________________________________________
> > > > 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
> > > >
> >
> > > _______________________________________________
> > > 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
> >