Make the type of (&) analogous to the one of ($)

[andreasabel]

Proposal: establish uniformity between ($) and (&). They are currently out of sync (base-4.18).

($) :: forall r a (b :: TYPE r). (a -> b) -> (a -> b)
(&) :: a -> (a -> b) -> b

I think when ($) was generalized to its present form, (&) was forgotten.

Proposal: change to

(&) :: forall r a (b :: TYPE r). a -> (a -> b) -> b

Note: #132 generalizes the type of ($) even further, but @phadej thinks the same is not possible for (&):

• Make ($) fully representation polymorphic #132 (comment)

Disclaimer: I'll probably won't make a MR myself.

[hasufell]

Note: this would keep the existing implementation.

x & f = f x

[Bodigrim]

I do not expect much fight over this, seems a very reasonable addition, but there is no way forward unless someone creates an MR and completes an impact assessment.

[mixphix]

@andreasabel The proposal process is outlined in this very repository. Could you please describe why you chose to ignore it when making this proposal?

[andreasabel]

@mixphix: As this very issue demonstrates, the process is somewhat broken, if it manages to pass a generalization of ($) from (a -> b) -> a -> b to the more polymorphic forall r a (b :: TYPE r). (a -> b) -> (a -> b) without doing the same for the twin (&). I think you can't replace expertise by a social process and voting. You need experts keeping an oversight over the big picture who can keep the library consistent.
Personally, atm I do not have the time to do this service, and I also do not have the time to become an expert for making and evaluating changes to base, which involves building GHC etc. I am an expert on other things and this is where I contribute to the Haskell community.
I still take the liberty to point out issues like this one (#158) to the responsible body.
Thanks to the CLC who have taken the responsibility for base!

[hasufell]

@andreasabel You're making several assumptions:

1. the types can be symmetric (they can't)
2. CLC values symmetry above all else (likely false as well)

Insulting volunteers will not get you bonus points for a sub-par proposal.

[andreasabel]

Insulting volunteers will not get you bonus points for a sub-par proposal.

I am not insulting volunteers, I am just not a believer that everything can be channeled through one process. I think you need a some kind of fast-track for such fixes, and some oversee that keeps the API consistent.

[hasufell]

I think you need a some kind of fast-track for such fixes, and some oversee that keeps the API consistent.

Again you're making assumptions.

[andreasabel]

Again you're making assumptions.

@hasufell : Sorry for making assumptions, that's human nature, I suppose. I am happy to read your personal CLC mission statement so I make less assumptions about your intentions.

Not sure if this discussion leads somewhere this way.

I don't really have anything to add. If you think this proposal is "right", then take it, otherwise leave it.

[hasufell]

I am happy to read your personal CLC mission statement so I make less assumptions about your intentions.

https://gist.github.com/hasufell/d9d33cc44f65163f493e09da311ef6a7

Not sure if this discussion leads somewhere this way.

Agreed. I propose to close this proposal due to lack of a champion (the issue creator indicated they won't create an MR).

[treeowl]

It's premature to close.

[hasufell]

It's premature to close.

Are you volunteering to champion the proposal?

[konsumlamm]

I'd be happy to create an MR for this, if noone else does.

[mixphix]

Thank you @konsumlamm for your generous offer.

[Bodigrim]

As this very issue demonstrates, the process is somewhat broken, if it manages to pass a generalization of ($) from (a -> b) -> a -> b to the more polymorphic forall r a (b :: TYPE r). (a -> b) -> (a -> b) without doing the same for the twin (&). I think you can't replace expertise by a social process and voting. You need experts keeping an oversight over the big picture who can keep the library consistent.

@andreasabel I'm not sure what's implied here. ($) has always been representationally-polymorphic in b (see ghc#5570, ghc#8739, ghc/ghc@5dd1cbb), it's just that its surface type in Haddock / ghci was a lie until base-4.12 (see ghc/ghc@321b420).

Putting responsibility for decade-old decisions made by experts on the current CLC seems at the very best unwise.

I still take the liberty to point out issues like this one (#158) to the responsible body.

If you want just to file an issue, but have no intent to fix it in the foreseeable future, I'd recommend using https://gitlab.haskell.org/ghc/ghc/-/issues.

It's reasonable to prioritise proposals with willing contributors over non-proposals / open-ended issues. The truth, however, is that we'll never get time for the second category, so there is no point to stockpile unactionable items.

I'd be happy to create an MR for this, if noone else does.

@konsumlamm could you please confirm that you are willing to create an MR and make an impact assessment as well?

[konsumlamm]

MR: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10338.

I decided to make r a specified type variable, as opposed to an inferred type variable, for symmetry with ($). This is technically a breaking change, however it's very unlikely to actually break something (it would only break uses of (&) with TypeApplications, there doesn't seem to be any such use on Hackage, according to https://hackage-search.serokell.io/?q=%5C%28%26%5C%29+%40). Making r an inferred type variable should not be a breaking change.

I can also try to make an impact assessment, when I get the time (hopefully this week).

[andreasabel]

@Bodigrim wrote:

If you want just to file an issue, but have no intent to fix it in the foreseeable future, I'd recommend using gitlab.haskell.org/ghc/ghc/-/issues.

Ok, thanks, I'll file issues there then, if this is the actual issue tracker for base.
I must say I am a bit confused about competencies here, I thought base was in the domain of CLC rather than GHC.
(And I was prompted by CLC to open this proposal here: #132 (comment).)

Anyway, thanks to @konsumlamm for volunteering!

[konsumlamm]

I tried to build clc-stackage and after some trouble trying to get it working, the only error is this:

Configuring library for hw-json-simd-0.1.1.2..
Preprocessing library for hw-json-simd-0.1.1.2..
c2hs: C header contains errors:

/usr/lib/gcc/x86_64-pc-linux-gnu/12.2.1/include/avx512fp16intrin.h:38: (column 18) [ERROR]  >>> Syntax error !
  The symbol `__v8hf' does not fit here.

Error: cabal: Failed to build hw-json-simd-0.1.1.2 (which is required by
clc-stackage-0.1.0.0). See the build log above for details.

This looks like a bug in c2hs to me, but I haven't found an existing bug report. Compiling hw-json-simd without the c2hs part works fine though (with my modified GHC).

So in summary: Everything in clc-stackage (that compiled before) compiles with the patch and I don't expect there to be any breakage (the only case I can think of that would break is using (&) with TypeApplications, which likely noone ever did).

[tbidne]

@konsumlamm Some more discussion on that problem here.

[Bodigrim]

Thanks @konsumlamm.

Dear CLC members, let's vote on the proposal to make (&) :: a -> (a -> b) -> b representation polymorphic in b:

-(&) :: a -> (a -> b) -> b
+(&) :: forall r a (b :: TYPE r). a -> (a -> b) -> b

This brings its type signature in line with ($) :: forall r a (b :: TYPE r). (a -> b) -> a -> b as in base-4.18.

(The further generalisation as for ($) in #132 is currently impossible for (&))

The MR is available at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10338/diffs. The impact assessment did not discover any breakage in the ecosystem.

@tomjaguarpaw @mixphix @chshersh @hasufell @angerman @parsonsmatt

---

+1 from me.

[parsonsmatt]

+1

[tomjaguarpaw]

-1

---

If we could match ($) precisely I would be in favour even though I voted against changing ($). Given that there are technical reasons that we can't I prefer to leave it as it is. I still think this stuff belongs in a putative "lifted-base" until it's been borne out to be good in practice.

[chshersh]

+1

[hasufell]

+1

[mixphix]

+1. I see no reason to stall nonbreaking generalizations.

[Bodigrim]

Thanks all, 5 votes in favour out of 7 possible are enough to approve.