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

[Graham Klyne]

[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.

#g
--

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)
>
>or
>
> > \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
>http://www.haskell.org/mailman/listinfo/haskell-cafe

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact