Proposal: simplify type of ($)

[Jeffrey Brown]

The Wiki says in a few places that Haskell only has one unary operator,
negation. those spots would need updating.

On Thu, Dec 28, 2017 at 8:04 AM, Ryan Trinkle <ryan.trinkle at gmail.com>
wrote:

> 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
>>
>>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
>


-- 
Jeff Brown | Jeffrey Benjamin Brown
Website <https://msu.edu/~brown202/>   |   Facebook
<https://www.facebook.com/mejeff.younotjeff>   |   LinkedIn
<https://www.linkedin.com/in/jeffreybenjaminbrown>(spammy, so I often miss
messages here)   |   Github <https://github.com/jeffreybenjaminbrown>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20171228/f8e1e1e2/attachment-0001.html>