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

[Simon Peyton Jones]

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

Simon

On Tue, 12 Mar 2024 at 09:33, Arnaud Spiwack <arnaud.spiwack at tweag.io>
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-1988401968
>
> 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 <malte.ott at maralorn.de> 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-quantification-order/proposals/0000-tyop-quantification-order.rst
>>
>> 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 at 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 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/20240312/3bdc66f4/attachment-0001.html>