is point free code more efficient, or just terser?

Question

I wrote the following code, which takes a bunch of points and draws them on the screen using the gloss library.

let s = blocks pes
    pts = map (map mkPt) s  {- stitches to points-}
    lines = map Line pts    {-points to lines -}
    pict = Pictures lines   {- lines to a picture -}
  in do  displayInWindow "My Window" (200, 200) (10, 10) white pict

It works fine, but it occurs to me that there's a repeated pattern: a chain of function calls, the result of each one feeding into the last argument of the next. So I refactored by removing the intermediate variables, reversing the order and chaining the functions with function composition (".") like so:

let pict = Pictures . (map Line) . (map $ map $ mkPt) . blocks $ pes
                in do  displayInWindow "My Window" (200, 200) (10, 10) white pict

Happily, this works just fine too. But I'm wondering if I'm straining readability, or if I'm just not used to reading & writing point free style code. Also, how do I reason about this code? Is the second version more efficient, or just terser? Is there anything I can do stylistically to make it clearer?

score 31 · Accepted Answer · answered Jun 27 '11 at 14:52

31

A few quick suggestions:

let pict = Pictures . (map Line) . (map $ map $ mkPt) . blocks $ pes
in do displayInWindow "My Window" (200, 200) (10, 10) white pict

You've got some superfluous stuff that can be removed outright:

let pict = Pictures . map Line . (map $ map mkPt) . blocks $ pes
in do displayInWindow "My Window" (200, 200) (10, 10) white pict

You're not avoiding parentheses anyway with the map (map mkPt) term, so get rid of the $:

let pict = Pictures . map Line . map (map mkPt) . blocks $ pes
in do displayInWindow "My Window" (200, 200) (10, 10) white pict

You can write the composition chain on multiple lines for clarity:

let pict = Pictures 
         . map Line 
         . map (map mkPt) 
         . blocks $ pes
in do displayInWindow "My Window" (200, 200) (10, 10) white pict

The do block is superfluous because it only has one statement, and you can move the final application outside the definition:

let displayPict = displayInWindow "My Window" (200, 200) (10, 10) white
                . Pictures 
                . map Line 
                . map (map mkPt) 
                . blocks
in displayPict pes

You can merge the two maps:

let displayPict = displayInWindow "My Window" (200, 200) (10, 10) white
                . Pictures 
                . map (Line . map mkPt) 
                . blocks
in displayPict pes

Sometimes it's also more readable for long chains to use the reversed composition operator from Control.Arrow:

let displayPict = blocks
                  >>> map (Line . map mkPt) 
                  >>> Pictures
                  >>> displayInWindow "My Window" (200, 200) (10, 10) white
in displayPict pes

But all of that is optional; season your code to taste.

On the subject of efficiency, I see no reason to think the two would be any different, once GHC's optimizer is through with the code.

answered Jun 27 '11 at 14:52

C. A. McCann

76,893
19
209
302

4

Indeed, the generated code should be the same for point free version. Without any optimization the point free code would be slight less efficient, because it has more function calls (of composition). – augustss Jun 27 '11 at 14:59
Wow, that's beautiful I didn't know about the reversed composition operator. Thanks! – nont Jun 27 '11 at 15:02
1

@augustss: Thanks for the confirmation--I wasn't certain, but the rearrangements are all pretty trivial and there didn't seem to be any differences as far as possible recomputation of subexpressions go. I tend not to worry about the "no optimizations" scenario unless the difference is dire, e.g. relying on the strictness analyzer to turn `foldl` into `foldl'` makes me uncomfortable. – C. A. McCann Jun 27 '11 at 15:21
2

@nont: `Arrow`s without the `proc` notation tend to require a lot of use of pointfree style, so there are several combinators in there that are useful--just read the `Arrow` instance in the type signatures as `(->)`, e.g. `(Arrow a) => a b c -> a b d -> a b (c, d)` becomes `(b -> c) -> (b -> d) -> b -> (c, d)`. – C. A. McCann Jun 27 '11 at 15:25
2

It should be mentioned that the let expression does not serve any purpose but to make it point free, the whole thing could be written as `displayInWindow "My Window" (200, 200) (10, 10) white . Pictures . map (Line . map mkPt) . blocks $ pes`. – HaskellElephant Jun 29 '11 at 10:56
2

Further, (>>>) make be exported by Control.Arrow but it is defined in Control.Category. It is also defined on the Category type-class, from which Arrow specialises. All Arrows instance Category, but not vice versa -- Lens comes to mind. In summary, I recommend using Control.Category directly if you are not going to use anything specific to Arrows. – Tony Morris Jul 14 '11 at 10:53
@Tony Morris: Oh, good point, thank you. I've gotten in the habit of just importing `Control.Arrow` because of `(&&&)` and `(***)`. I actually don't really care for `Arrow` itself (or, to be specific, `arr`). – C. A. McCann Jul 14 '11 at 13:51

score 4 · Answer 2 · answered Jun 29 '11 at 17:49

Point free style can be good to very clearly show that a function is simply a series of transformations on an input. It's really easy to read something like:

foo = map show . doThis . doThat . etc

because it looks like typical point-free code, so someone familiar with it will be able to see exactly what's important, with no noise. Compare this to:

foo x = d
    where
        a = etc x
        c = doThis b
        b = doThat a
        d = map show c

Obviously, this is a little contrived, but the idea is that the extra definitions need to be read and closely paid attention to in order to understand what foo is really doing. Is a used as an argument to more than one helper function? What about b? Did the data flow through these helper functions in a way that was unexpected? Point free style in this case is saying "Things are just being transformed in a pipeline, there's no weirdness you need to think about"

In other cases, point-free style can really obfuscate things. Generally that's when you would break out the lets and wheres. So, terseness isn't really the only goal, reducing mental load is important as well. (As others have commented, point free style shouldn't have a performance difference in optimized code).

is point free code more efficient, or just terser?

2 Answers2