Applicative ((->) c) methods

[Carter Schonwald]

hey Keith,
when emailing to the library list, linking to the source code you're
referring to:
http://hackage.haskell.org/package/base-4.11.0.0/docs/src/GHC.Base.html#line-804

can be super helpful for making sure everyone is on the same page ! (i
think i'm linking to the right code, plz confirm!)

unless the commit history indicates otherwise, i'd presume any current
choices in base are largely a product of historical reasons and or the
style of whomever wrote it most recently?

you are absolutely correct that when it comes to inlining,  "foo = \x ->
.. " will always satisfy the saturation condition to get inlined, while
"foo x = ..." will only be marked saturated when fully applied, (and this
of course ignoring how specializing the type class instances of a piece of
code behaves!)

i do generally agree that the RHS style you allude to is very handy when i
"know" that the definition should essentially simplify/partial evaluate
away to some function application and or let expression (especially if the
resulting code looks non recursive! ) to help ghc along, though excessive
inlining can be quite bad too! (Austin Seipp and Edward K have some really
good long comments on reddit etc about this, though i cant find the
particular one i'm thinking of by austin from a few years back).

one point Austin made was along the lines of: if you have to tell ghc
when/how to inline something to get good performance, this should be
treated as a bug (by and large).

though of course for core libraries interfaces/definitions/performance
critical primops, that guidance isn't necessarily the right default

I think the best approach to grounding these sorts of performance motivated
changes is to

1) write a tiny application / benchmark demonstrator with your own locally
defined / newtypy versions of both definitions you wanna compare
2) if need be, compare two versions of the same commit of ghc etc, (with
one having the proposed change set in base), and running nofib et al  to
have a statistical characterization of impact!

That said, i definitely agree with the implication that point free style
(aka partially applied ) code using the (-> r) applicative/monad
definitions, such as might be found in the lens library "over" and friends,
may or may not benefit from this sort of change. Though i suspect Eric
Mertens or Edward K or Ryan Scott might have better clarity on that


Thanks for taking the time to think about this and ask/start a discussion! '

-Carter

On Mon, Nov 18, 2019 at 3:40 PM Keith <keith.wygant at gmail.com> wrote:

> Just thinking for Applicative ((->) c)
> (<*) = const
> (*>) = flip const -- or \ _ x -> x
>
> Is it because we can rely on GHC to produce the same code from the current
> definitions?
>
>
> Also wondering why Monad uses
> f >>= k = \ r -> k (f r) r
>
> but Applicative uses
> (<*>) f g x = f x (g x)
> liftA2 q f g x = q (f x) (g x)
>
> Seems like if it's style/legibility, it should be consistent between (>>=)
> and (<*>). And if it's inlining issue, we'd want lambdas for all three.
>
> --Keith
> --
> Sent from my phone with K-9
> Mail._______________________________________________
> 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/20191118/8d23aee7/attachment.html>