Proposal: simplify type of ($)

[Ryan Trinkle]

Agreed.  I've always taught ($) as "a parenthesis that goes as far forward
as it can".  That seems to be a pretty good heuristic for people to use,
and it's a whole lot easier than explaining operator precedence in enough
detail that the behavior becomes clear from first principles.

On Wed, Dec 27, 2017 at 9:39 PM, Theodore Lief Gannon <tanuki at gmail.com>
wrote:

> So far as pedagogy is concerned, ($) is already one of those things people
> tend to learn how to use before they really understand the mechanism. And
> for my part, I think if it were immediately obvious that it's just infix
> id, it would have helped my early understanding of id! +1 from the peanut
> gallery.
>
> On Dec 27, 2017 6:17 PM, "David Feuer" <david.feuer at gmail.com> wrote:
>
>> Currently, we have something like
>>
>>     ($) :: forall r1 r2 (a :: TYPE r1) (b :: TYPE r2).
>>       (a -> b) -> a -> b
>>     f $ x = f x
>>
>> And that's only part of the story: GHC has a hack in the type checker to
>> give ($) an impredicative type when fully applied. This allows it to be
>> used when its function argument requires a polymorphic argument.
>>
>> This whole complicated situation could be resolved in a very simple
>> manner: change the type and definition thus.
>>
>>     ($) :: a -> a
>>     ($) f = f
>>
>> All the type complications go away altogether, and ($) becomes plain
>> Haskell 98.
>>
>> There are only three potential downsides I can think of:
>>
>> 1. The optimizer will see `($) x` as fully applied, which could change
>> its behavior in some cases. There might be circumstances where that is bad.
>> I doubt there will be many.
>>
>> 2. The new type signature may obscure the purpose of the operator to
>> beginners. But based on my experience on StackOverflow, it seems beginners
>> tend to struggle with the idea of ($) anyway; this may not make it much
>> worse. I suspect good Haddocks will help alleviate this concern.
>>
>> 3. Some type family and class instances may not be resolved under certain
>> circumstances which I suspect occur very rarely in practice.
>>
>>     class C a where
>>       m :: (a -> a) -> ()
>>     instance C (a -> b) where
>>       m _ = ()
>>     test :: ()
>>     test = m ($)
>>
>> Today, this compiles with no difficulties; with the proposed change, the
>> user would have to supply a type signature to make it work:
>>
>>     test = m (($) :: (a -> b) -> (a -> b))
>>
>> This can also change when an INCOHERENT instance is selected under
>> similarly contrived circumstances, but those who use such generally deserve
>> what they get.
>>
>> David
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20171228/e399066f/attachment.html>