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

Thu Mar 21 17:46:57 UTC 2024

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