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

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 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 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@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 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@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@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

...

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

...

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

...

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

...

...

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee