<div dir="ltr"><div>hey Keith,</div><div>when emailing to the library list, linking to the source code you're referring to: <a href="http://hackage.haskell.org/package/base-4.11.0.0/docs/src/GHC.Base.html#line-804" target="_blank">http://hackage.haskell.org/package/base-4.11.0.0/docs/src/GHC.Base.html#line-804</a> </div><div>can be super helpful for making sure everyone is on the same page ! (i think i'm linking to the right code, plz confirm!)</div><div><br></div>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? <div><br></div><div>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!)</div><div><br></div><div>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).  </div><div><br></div><div>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). </div><div><br></div><div>though of course for core libraries interfaces/definitions/performance critical primops, that guidance isn't necessarily the right default</div><div><br></div><div>I think the best approach to grounding these sorts of performance motivated changes is to <br></div><div><br></div><div>1) write a tiny application / benchmark demonstrator with your own locally defined / newtypy versions of both definitions you wanna compare</div><div>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! </div><div><br></div><div>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</div><div><br></div><div><br></div><div>Thanks for taking the time to think about this and ask/start a discussion! '</div><div><br></div><div>-Carter</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 18, 2019 at 3:40 PM Keith <<a href="mailto:keith.wygant@gmail.com" target="_blank">keith.wygant@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Just thinking for Applicative ((->) c)<br>  (<*) = const<br>  (*>) = flip const -- or \ _ x -> x<br><br>Is it because we can rely on GHC to produce the same code from the current definitions?<br><br><br>Also wondering why Monad uses <br>  f >>= k = \ r -> k (f r) r<br><br>but Applicative uses<br>  (<*>) f g x = f x (g x)<br>  liftA2 q f g x = q (f x) (g x)<br><br>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.<br><br>--Keith<br>-- <br>Sent from my phone with K-9 Mail._______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>