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.