[Haskell-cafe] Point-free style (Was: Things to avoid)

Graham Klyne GK at ninebynine.org
Tue Feb 15 04:29:40 EST 2005

[I drafted this response some time ago, but didn't send it, so apologies if 
I am re-covering old ground...]

At 09:23 10/02/05 -0500, Jan-Willem Maessen wrote:
>If you're trying to avoid obscurity, why advocate point-free style?

Some time ago, I asked an experienced Haskell programmer about the extent 
to which they used point-free style in day-to-day programming, and the 
response I got was to the effect that they use point-full style a fair amount.

The ...er... point, I think, is that it is easier to reason equationally 
with point-free programs, even if the intended computation is often easier 
for mere mortals to see when named values are used.  So point-free style 
helps when trying to apply program transformation techniques, and 
translation to make greater use of point-free idioms may be a useful 
precursor to transforming a program.

Something I have noticed is that, as one gets more used to using higher 
order functions, it is often more elegant to express a computation by 
composition of functions, but in so doing one has to discard preconceived 
notions of what makes an efficient program.

I think it comes down to this: learn to be comfortable with both styles, 
and be prepared to use the one that best expressed the intended solution 
(and is easiest to understand) in any given context.


At 09:23 10/02/05 -0500, Jan-Willem Maessen wrote:
>If you're trying to avoid obscurity, why advocate point-free style?
>I ask this question to be deliberately provocative; I'm not trying to 
>single you out in particular.  So, to everybody: What's so great about 
>point-free style?
>Is it really clear or obvious what
> > map . (+)
>means?  Contrast this with
> > \n -> map (+n)
> > \n xs -> map (+n) xs
>I submit that, while it is possible to develop a reading knowledge of 
>point-free style, non-trivial use of point-free 
>computations---compositions of functions with arity greater than 1, as 
>above, compositions of sections of composition or application, arrow 
>notation without the sugar, and so forth---will always be more difficult 
>to read and understand than the direct version.  I submit that this is 
>true even if one is familiar with point-free programming and skilled in 
>its use.
>Even something as simple as eta-reduction (as in the second and third 
>functions above) can seriously obscure the meaning of program code by 
>concealing the natural arity of a function.
>-Jan-Willem Maessen
>Haskell-Cafe mailing list
>Haskell-Cafe at haskell.org

Graham Klyne
For email:

More information about the Haskell-Cafe mailing list