<div dir="ltr"><blockquote class="gmail_default gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As I wrote on GH, I'm not convinced by the change for infix type <br>
operators (the linear arrows change is fine).

</blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">I don't agree with your intuition on infix operators.  As I wrote on GH:</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<blockquote dir="auto" class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I sympathise with this, but <em>any</em> specification amounts to specify some linearisation of the tree.   Your mental linearisation puts the function of  (a <code class="gmail-notranslate">op</code> b) first; and mine does to.  BUT I don't want us to have to specify a linearisation function, because <strong>we already have one</strong>:
 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.</blockquote><div><br></div><div>But I think you are now saying that <i>even if a left-to-right order was "best", </i>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.  <br></div><div><br></div><div>A change would break code like</div><div style="margin-left:40px">f :: a `m` b -> (a,b)</div><div style="margin-left:40px">...</div><div style="margin-left:40px">foo = ...(f @Either @Int <a class="gmail_plusreply" id="plusReplyChip-2">@Bool)...</a></div><div style="margin-left:40px"><a class="gmail_plusreply" id="plusReplyChip-2"><br></a></div><a class="gmail_plusreply" id="plusReplyChip-2">where we have</a></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><ul><li>An infix type operator that is a variable</li><li>Other type variables in the first argument of the infix application</li><li>No type-class constraint  (Wombat m => a `m` b) would put `m` first.</li><li>Visible type applications in at least one calls site</li></ul><div>So yes, it's an un-forced breakage.  So maybe institutionalising the exception into the spec is the right thing to do.</div><div><br></div><div>I would love to hear from other members of the committee with more user-centric experience.</div><div><br></div><div>Simon<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 19 Mar 2024 at 08:18, Adam Gundry <<a href="mailto:adam@well-typed.com">adam@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As I wrote on GH, I'm not convinced by the change for infix type <br>
operators (the linear arrows change is fine). The odds of breakage are <br>
slight, but non-zero, and it's a particularly nasty form of breakage <br>
because a library may use an infix operator but the changed <br>
quantification order only affect downstream code using that library with <br>
TypeApplications. Perhaps nobody will be affected, but if someone is, <br>
they would have some justification to feel aggrieved at this change!<br>
<br>
If there was a compelling benefit to changing the status quo, this could <br>
be justifiable, but in this case I don't really see the harm in carving <br>
out an exception for infix operators from the usual "quantification is <br>
left-to-right" rule.<br>
<br>
Adam<br>
<br>
<br>
On 17/03/2024 14:15, Eric Seidel wrote:<br>
> I agree with Simon's intuition on GH, and support acceptance as-is.<br>
> <br>
> On Wed, Mar 13, 2024, at 02:57, Moritz Angermann wrote:<br>
>> I feel myself agreeing with Arnaud on this. The LH part is a no<br>
>> brainer, the infix op, i'm not fully convinced. But I'll trust Simon's<br>
>> intuition here.<br>
>><br>
>> Simons comment reminded me I need to urgently get back to the<br>
>> -experimental proposal.<br>
>><br>
>> On Tue, 12 Mar 2024 at 18:59, Simon Peyton Jones<br>
>> <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>> wrote:<br>
>>> I think we should accept the proposal as-is.  See my comment: <a href="https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1991255204" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1991255204</a><br>
>>><br>
>>> Simon<br>
>>><br>
>>> On Tue, 12 Mar 2024 at 09:33, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<br>
>>>> I think that the linear types part is a no-brainer.<br>
>>>><br>
>>>> 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 <a href="https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1988401968" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1988401968</a><br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>> On Sat, 9 Mar 2024 at 22:46, Malte Ott <<a href="mailto:malte.ott@maralorn.de" target="_blank">malte.ott@maralorn.de</a>> wrote:<br>
>>>>> Dear all,<br>
>>>>><br>
>>>>> Vlad proposes to change the order of implicit quantification for type<br>
>>>>> variables occurring as type operators or in multiplicity annotations:<br>
>>>>><br>
>>>>> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/640" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/640</a><br>
>>>>><br>
>>>>> <a href="https://github.com/int-index/ghc-proposals/blob/int-index/tyop-quantification-order/proposals/0000-tyop-quantification-order.rst" rel="noreferrer" target="_blank">https://github.com/int-index/ghc-proposals/blob/int-index/tyop-quantification-order/proposals/0000-tyop-quantification-order.rst</a><br>
>>>>><br>
>>>>> The proposal is thankfully very simple. Change the implicit quantification order for<br>
>>>>><br>
>>>>> "a `op` b" from "forall op a b" to "forall a op b".<br>
>>>>><br>
>>>>> and<br>
>>>>><br>
>>>>> "a %m -> b" from "forall a b m" to "forall a m b".<br>
>>>>><br>
>>>>> The proposed new behavior corresponds to the original paper and our user guide.<br>
>>>>> This can be considered a bug fix and while we could also just change the<br>
>>>>> specification I think having a simple and memorable rule for quantification<br>
>>>>> order is valuable. Especially the currently implemented quantification order for<br>
>>>>> multiplicities is weird.<br>
>>>>><br>
>>>>> The only painful point here is as usual a question of stability. What I don’t<br>
>>>>> like about this change is, that if any code base uses it (which Vlad doubts and<br>
>>>>> I tend to agree), the type error on GHC upgrade will be very incomprehensible<br>
>>>>> for users who didn’t read and understand the changelog.<br>
>>>>><br>
>>>>> However multiplicities are new and explicitely unstable and I don’t really see a<br>
>>>>> reason why anyone would use infix notation on a qantified function. So I agree<br>
>>>>> that this very unlikely to happen in the wild. Also, users who rely on the type<br>
>>>>> application order right now should have noticed that something is off.<br>
>>>>><br>
>>>>> Thus I recommend acceptance as is.<br>
>>>>><br>
>>>>> Please voice your opinions!<br>
>>>>><br>
>>>>> Malte<br>
<br>
<br>
-- <br>
Adam Gundry, Haskell Consultant<br>
Well-Typed LLP, <a href="https://www.well-typed.com/" rel="noreferrer" target="_blank">https://www.well-typed.com/</a><br>
<br>
Registered in England & Wales, OC335890<br>
27 Old Gloucester Street, London WC1N 3AX, England<br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>