<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">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">https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1991255204</a></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 12 Mar 2024 at 09:33, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io">arnaud.spiwack@tweag.io</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"><div dir="ltr"><div dir="ltr"><div>I think that the linear types part is a no-brainer.</div><div><br></div><div>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" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/640#issuecomment-1988401968</a></div><div><br></div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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>
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><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div></div>
_______________________________________________<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>