Inline semigroupoidArr composition

[puffnfresh]

An example of the changes:

g :: Boolean
g = not <<< not $ true

f :: Boolean -> Boolean
f = not <<< not <<< not <<< not

f' x = (\y -> f y) x

var g = !!true;

var f = function (_44) {
    return !!!!_44;
};

var f$prime = function (x) {
    return f(x);
};

I did the following:

1. Allowed everywhereOnJSTopDown to work in a Monad, default is Identity.
2. Made untiFixedPoint work on a Monad.
3. Added inlineAppliedVars optimisation, turning (\x -> f x) y into f y.
4. Added inlineArrComposition optimisation, turning a >>> b into (\x -> a (b x)).

What are the drawbacks?

Should fix #1066.

[coveralls]

Coverage increased (+0.04%) to 78.37% when pulling a411755 on puffnfresh:optimisation/inline-semigroupoid-arr into fa59cf1 on purescript:master.

[coveralls]

Coverage increased (+0.04%) to 78.37% when pulling a411755 on puffnfresh:optimisation/inline-semigroupoid-arr into fa59cf1 on purescript:master.

[garyb]

Looks great to me, and good call on the Identity monad, I think we have some AST traversals we could have done that with.

[garyb]

Looks great to me, and good call on the Identity monad, I think we have some AST traversals we could have done that with.

[paf31]

Looks good, thanks!

I'm always wary of inlining operations, since they have broken code in odd ways in the past. In this case, I thought the existing inlining code would have taken care of it, so I'd like to figure out why not:

https://github.com/purescript/purescript/blob/master/src/Language/PureScript/CodeGen/JS/Optimizer/Inliner.hs#L48

That code is very strict in terms of what it accepts, but only because so much code has broken in the past, and it's been changed a few times.

What is the set of transformations we want to enable, and can we figure out why the existing optimization isn't firing?

The fresh name code and <<< optimization look great. Should we optimize >>> too?

[paf31]

Looks good, thanks!

I'm always wary of inlining operations, since they have broken code in odd ways in the past. In this case, I thought the existing inlining code would have taken care of it, so I'd like to figure out why not:

https://github.com/purescript/purescript/blob/master/src/Language/PureScript/CodeGen/JS/Optimizer/Inliner.hs#L48

That code is very strict in terms of what it accepts, but only because so much code has broken in the past, and it's been changed a few times.

What is the set of transformations we want to enable, and can we figure out why the existing optimization isn't firing?

The fresh name code and <<< optimization look great. Should we optimize >>> too?

[puffnfresh]

@paf31 I removed inlineAppliedVars. At some point it seemed like it was making (<<<) work but now it doesn't seem necessary. I imagine the (<<<) optimisation just wasn't working properly at the time.

[puffnfresh]

@paf31 I removed inlineAppliedVars. At some point it seemed like it was making (<<<) work but now it doesn't seem necessary. I imagine the (<<<) optimisation just wasn't working properly at the time.

[paf31]

Looks good. I'll just wait for the CI build to finish.

[paf31]

Looks good. I'll just wait for the CI build to finish.

[coveralls]

Coverage increased (+0.03%) to 78.35% when pulling e929327 on puffnfresh:optimisation/inline-semigroupoid-arr into fa59cf1 on purescript:master.

[coveralls]

Coverage increased (+0.03%) to 78.35% when pulling e929327 on puffnfresh:optimisation/inline-semigroupoid-arr into fa59cf1 on purescript:master.