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

[Simon Peyton Jones]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240408/f0b11216/attachment-0001.html>