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.
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
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
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.orghttps://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