I think we should accept the proposal as-is. See my comment: https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1991255... Simon On Tue, 12 Mar 2024 at 09:33, Arnaud Spiwack wrote:

I think that the linear types part is a no-brainer.

The infix operator one is less clear. Adam feels that it'd be weird if “a `op` b” yielded a different order than “op a b” as is being proposed. It's definitely something you could go both ways about. I'm personally worried about backward compatibility. Admittedly, this case where we quantify implicitly over a variable in infix position is probably rare. But the breakage would be quite subtle. I'm just not sure it's worth it. Do we care enough about the order of implicit quantification that we want to change this long established one? Richard is more optimistic https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1988401...

So, anyway, I'm open to be swayed by arguments, but my current thinking is: make the change for a %m -> b, but not for a `op` b.

On Sat, 9 Mar 2024 at 22:46, Malte Ott wrote:

...

Dear all,

Vlad proposes to change the order of implicit quantification for type variables occurring as type operators or in multiplicity annotations:

https://github.com/ghc-proposals/ghc-proposals/pull/640

https://github.com/int-index/ghc-proposals/blob/int-index/tyop-quantificatio...

The proposal is thankfully very simple. Change the implicit quantification order for

"a `op` b" from "forall op a b" to "forall a op b".

and

"a %m -> b" from "forall a b m" to "forall a m b".

The proposed new behavior corresponds to the original paper and our user guide. This can be considered a bug fix and while we could also just change the specification I think having a simple and memorable rule for quantification order is valuable. Especially the currently implemented quantification order for multiplicities is weird.

The only painful point here is as usual a question of stability. What I don’t like about this change is, that if any code base uses it (which Vlad doubts and I tend to agree), the type error on GHC upgrade will be very incomprehensible for users who didn’t read and understand the changelog.

However multiplicities are new and explicitely unstable and I don’t really see a reason why anyone would use infix notation on a qantified function. So I agree that this very unlikely to happen in the wild. Also, users who rely on the type application order right now should have noticed that something is off.

Thus I recommend acceptance as is.

Please voice your opinions!

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

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I agree with Simon's intuition on GH, and support acceptance as-is. On Wed, Mar 13, 2024, at 02:57, Moritz Angermann wrote:

I feel myself agreeing with Arnaud on this. The LH part is a no brainer, the infix op, i'm not fully convinced. But I'll trust Simon's intuition here.

Simons comment reminded me I need to urgently get back to the -experimental proposal.

On Tue, 12 Mar 2024 at 18:59, Simon Peyton Jones wrote:

...

I think we should accept the proposal as-is. See my comment: https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1991255...

Simon

On Tue, 12 Mar 2024 at 09:33, Arnaud Spiwack wrote:

...

I think that the linear types part is a no-brainer.

The infix operator one is less clear. Adam feels that it'd be weird if “a `op` b” yielded a different order than “op a b” as is being proposed. It's definitely something you could go both ways about. I'm personally worried about backward compatibility. Admittedly, this case where we quantify implicitly over a variable in infix position is probably rare. But the breakage would be quite subtle. I'm just not sure it's worth it. Do we care enough about the order of implicit quantification that we want to change this long established one? Richard is more optimistic https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1988401...

So, anyway, I'm open to be swayed by arguments, but my current thinking is: make the change for a %m -> b, but not for a `op` b.

On Sat, 9 Mar 2024 at 22:46, Malte Ott wrote:

...

Dear all,

Vlad proposes to change the order of implicit quantification for type variables occurring as type operators or in multiplicity annotations:

https://github.com/ghc-proposals/ghc-proposals/pull/640

https://github.com/int-index/ghc-proposals/blob/int-index/tyop-quantificatio...

The proposal is thankfully very simple. Change the implicit quantification order for

"a `op` b" from "forall op a b" to "forall a op b".

and

"a %m -> b" from "forall a b m" to "forall a m b".

The proposed new behavior corresponds to the original paper and our user guide. This can be considered a bug fix and while we could also just change the specification I think having a simple and memorable rule for quantification order is valuable. Especially the currently implemented quantification order for multiplicities is weird.

The only painful point here is as usual a question of stability. What I don’t like about this change is, that if any code base uses it (which Vlad doubts and I tend to agree), the type error on GHC upgrade will be very incomprehensible for users who didn’t read and understand the changelog.

However multiplicities are new and explicitely unstable and I don’t really see a reason why anyone would use infix notation on a qantified function. So I agree that this very unlikely to happen in the wild. Also, users who rely on the type application order right now should have noticed that something is off.

Thus I recommend acceptance as is.

Please voice your opinions!

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

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ 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

As I wrote on GH, I'm not convinced by the change for infix type operators (the linear arrows change is fine). I don't agree with your intuition on infix operators. As I wrote on GH: I sympathise with this, but *any* specification amounts to specify some

linearisation of the tree. Your mental linearisation puts the function of (a op b) first; and mine does to. BUT I don't want us to have to specify a linearisation function, because *we already have one*: it's called "look at the left to right order of what the user wrote". It may not be a great linearisation function, but it is simple, easy to specify, no further explanation needed.

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. A change would break code like f :: a `m` b -> (a,b) ... foo = ...(f @Either @Int @Bool)... where we have - An infix type operator that is a variable - Other type variables in the first argument of the infix application - No type-class constraint (Wombat m => a `m` b) would put `m` first. - Visible type applications in at least one calls site So yes, it's an un-forced breakage. So maybe institutionalising the exception into the spec is the right thing to do. I would love to hear from other members of the committee with more user-centric experience. Simon On Tue, 19 Mar 2024 at 08:18, Adam Gundry wrote:

As I wrote on GH, I'm not convinced by the change for infix type operators (the linear arrows change is fine). The odds of breakage are slight, but non-zero, and it's a particularly nasty form of breakage because a library may use an infix operator but the changed quantification order only affect downstream code using that library with TypeApplications. Perhaps nobody will be affected, but if someone is, they would have some justification to feel aggrieved at this change!

If there was a compelling benefit to changing the status quo, this could be justifiable, but in this case I don't really see the harm in carving out an exception for infix operators from the usual "quantification is left-to-right" rule.

Adam

...

I agree with Simon's intuition on GH, and support acceptance as-is.

On Wed, Mar 13, 2024, at 02:57, Moritz Angermann wrote:

...

I feel myself agreeing with Arnaud on this. The LH part is a no brainer, the infix op, i'm not fully convinced. But I'll trust Simon's intuition here.

Simons comment reminded me I need to urgently get back to the -experimental proposal.

On Tue, 12 Mar 2024 at 18:59, Simon Peyton Jones wrote:

...

I think we should accept the proposal as-is. See my comment: https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1991255...

Simon

On Tue, 12 Mar 2024 at 09:33, Arnaud Spiwack wrote:

...

I think that the linear types part is a no-brainer.

The infix operator one is less clear. Adam feels that it'd be weird if “a `op` b” yielded a different order than “op a b” as is being proposed. It's definitely something you could go both ways about. I'm personally worried about backward compatibility. Admittedly, this case where we quantify implicitly over a variable in infix position is probably rare. But

...

...

...

...

So, anyway, I'm open to be swayed by arguments, but my current

...

...

...

...

On Sat, 9 Mar 2024 at 22:46, Malte Ott wrote:

...

Dear all,

Vlad proposes to change the order of implicit quantification for type variables occurring as type operators or in multiplicity annotations:

https://github.com/ghc-proposals/ghc-proposals/pull/640

https://github.com/int-index/ghc-proposals/blob/int-index/tyop-quantificatio...

...

...

The proposal is thankfully very simple. Change the implicit

quantification order for

...

"a `op` b" from "forall op a b" to "forall a op b".

and

"a %m -> b" from "forall a b m" to "forall a m b".

The proposed new behavior corresponds to the original paper and our

user guide.

...

This can be considered a bug fix and while we could also just change

On 17/03/2024 14:15, Eric Seidel wrote: the breakage would be quite subtle. I'm just not sure it's worth it. Do we care enough about the order of implicit quantification that we want to change this long established one? Richard is more optimistic https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1988401... thinking is: make the change for a %m -> b, but not for a `op` b. the

...

...

...

...

...

specification I think having a simple and memorable rule for quantification order is valuable. Especially the currently implemented quantification order for multiplicities is weird.

The only painful point here is as usual a question of stability. What I don’t like about this change is, that if any code base uses it (which Vlad doubts and I tend to agree), the type error on GHC upgrade will be very incomprehensible for users who didn’t read and understand the changelog.

However multiplicities are new and explicitely unstable and I don’t really see a reason why anyone would use infix notation on a qantified function. So I agree that this very unlikely to happen in the wild. Also, users who rely on the type application order right now should have noticed that something is off.

Thus I recommend acceptance as is.

Please voice your opinions!

Malte

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

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

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

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 mailto:malte.ott@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@gmail.com mailto: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 mailto: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 mailto: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

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

The vote is clear enough then and I have accepted the proposal. Thanks for the discussion! Best Malte On 2024-04-08 17:31, Simon Peyton Jones wrote:

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