[Haskell-cafe] New type of ($) operator in GHC 8.0 is problematic

[Tom Ellis]

On Sat, Feb 06, 2016 at 12:31:57PM +0000, Tom Ellis wrote:
> On Sat, Feb 06, 2016 at 01:27:00PM +0100, Ben Gamari wrote:
> > Tom Ellis <tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> writes:
> > > On Fri, Feb 05, 2016 at 07:19:25PM +0000, Tom Ellis wrote:
> > >> On Fri, Feb 05, 2016 at 01:13:23PM -0500, Richard Eisenberg wrote:
> > >> > We're in a bit of a bind in all this. We really need the fancy type for
> > >> > ($) so that it can be used in all situations where it is used currently. 
> > >> 
> > >> Is there a list of situations where ($) is used currently that give rise to
> > >> this need?
> > >
> > > Does anyone have any idea about this?  What is it about ($) that means it
> > > needs a new funky type whereas (apparently) nothing else does?
> > 
> > The first (albeit rather unconvincing) example I can think of is be
> > something like,
> > 
> >     getI# :: Int -> Int#
> >     getI# (I# n#) = n#
> > 
> >     n# :: Int#
> >     n# = getI# $ 5 + 8
> > 
> > Richard likely has something a bit less contrived though.
> 
> I hope there's something less contrived, because if the benefit is "you get
> to use $ to apply functions whose return type is not of kind *" then the
> power to weight ratio of this is extremely low.

No one has suggested anything less contrived, so I'm going to assume this
encompasses all use cases for the new type.  in which case may I make a
counter proposal:

    Give Prelude.($) a truthful type of '(a -> b) -> a -> b' and put the
    generalized version in a separate module, at least for now?

I note that with the Foldable/Traversable Prelude we had

    * Foldable and Traversable in separate modules for a long, long time
    * A long discussion about merging them
    * Lots and lots of people using Foldable and Traversable

None of these cases seems to apply to generalized ($) so I don't think it
warrants inclusion in base (yet).

(This is not to suggest that the work on the type system to make this sort
of polymorphism is not technically excellent -- I just think we need to hold
fire regarding merging such changes to base).

Tom