
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
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
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