Move arguments to the right side of the =?

[shachaf]

We have definitions like

over l f = runMutator# (l (mutator# f))

If we turn this into

over l = \f -> runMutator# (l (mutator# f))

GHC can inline it better in a call like

foo :: (a -> b) -> [a] -> [b]
foo = over mapped

Since the application is saturated, even if foo doesn't end up getting inlined.

Our strategy in lens has mostly been "inline everything, and let GHC simplify it down to nothing at the use site", so this probably wouldn't cause any harm.

[pthariensflame]

It would also let you use point-free style, but that might alter strictness (again).

[ekmett]

I am a strong +1 for doing this where it makes sense.

Let's target 3.8.

[ekmett]

Interestingly all of the recent indexed work has moved us in the wrong direction on this issue. =/

[ekmett]

Apparently we didn't target 3.8 with it. =P

Are we still interested in making this happen?

[shachaf]

Sounds reasonable -- someone just needs to go through the code and do it wherever it makes sense. I just tested and this sort of thing is still being under-inlined, so it'll still help to do it.

[ocharles]

Could you provide any pointers on how to judge whether it "makes sense"? I would be interested in providing a PR.

[ekmett]

Well, if it is a combinator that is often not fully applied then you may want to move the arguments, the ones that we don't usually apply all at once, to the other side of the = to get better inlining behavior.

An example consider _2._3._1.both

When we build up a lens/traversal chain like that the last 2 arguments are virtually universally not applied.

So we're relying on GHC deciding to take foo ^. _2._3.both

and inline ^. which it is pretty good about doing, then seeing that once that is inlined, that

(.) (_2._3) both Const foo

is applied to enough arguments, to get that to inline, etc.

all the way up the chain, THEN it finally gets to start making newtypes go away (if you implement these naively).

If we moved

both f (a,b) = (,) <$> f a <*> f b

to

both = \f (a,b) -> (,) <$> f a <*> f b

it may not win much, but it at least allows the inlining decision to happen earlier rather than on a rigid ordering imparted by driving lens combinator.

For both it probably doesn't matter, but for things like at i or more complicated lenses / traversals it could theoretically help a lot with getting more inlining in more situations.

[raymoo]

How is 8ae6bec?

[ekmett]

Looks pretty good. I really do hate let notation, but the only alternative there is

case foo of
  mv -> ...

[ekmett]

Potential issue that may affect this: https://ghc.haskell.org/trac/ghc/ticket/11029#comment:1

[glguy]

With our aggressive inlining I think that this is less of an issue. Inlining happens before optimizations. Additionally we aren't using this argument trick to share pattern matching; we're using it to influence the inliner.

I did a test of the code attached to that ticket and an inline pragma on test1 allows the test to run as quickly as the version with trace