
Point-Free style: What is it good for? - bkudria
http://buffered.io/2009/06/27/point-free-style-what-is-it-good-for/
======
mbrubeck
I just like point-free style because it leaves me with fewer things to name,
and fewer choices to make. Placeholder names like "xs" are just noise. The "x"
has no meaning here:

    
    
        double x = 2*x 
    

So I'd rather write it like this:

    
    
        double = (2*)
    

Similarly, there's no need to introduce an arbitrary name like "input" or
"numbers" for this function (part of a Project Euler solution):

    
    
        highestProduct = maximum . map product . concat . map (groupsOf 4)

------
hristov
First I would like to say that I am only learning Haskell, and have done
nothing but toy programs thus far. But the point free style is something that
I really do not like about Haskell. It makes code much more complicated for
the dubious benefit of saving a couple of keystrokes.

For example, take the code from the article:

This is without point free style: sum xs = foldr (+) 0 xs

And this is with: sum = foldr (+) 0

You have saved a total of 4 keystrokes. And made that line of code look really
weird and hard to understand.

Thus, now when you look at code you cannot say at first glance how many
arguments a function takes. The second line of code looks like sum takes 0
arguments. But you have to look more carefully at the definition of the
function, and see that it uses foldr, and know that foldr takes three
arguments, but here only two are defined, and then you figure out that someone
is using point free style and then you figure out that sum, actually takes one
argument that must be a list.

And this of course, is a simple example. Here we have a big clue in that the
function is defined with zero arguments, and most functions take at least one
argument, therefore the function probably uses the point free notation. But
for a more complex and longer function, the point free style can very easily
confuse someone reading the code.

So yeah, I think point free style is one of these annoying features of
Haskell, that seem to be put in so that users of Haskell can pat themselves on
the back and feel like they are very smart. But in the end it does not add
much to the language and makes it much less accessible.

~~~
mbrubeck
Once you're used to the idiom, I find point-free style at least as easy to
read as pointful.

 _"Thus, now when you look at code you cannot say at first glance how many
arguments a function takes."_

In Haskell I generally look at the type signature - explicit or inferred - to
see what a functions' arguments are.

I find this style is actually more beneficial for larger-scale examples than
smaller ones. For example, if you have a memoizing combinator, most people
would not find it odd at all to write:

    
    
      fast_factorial = memoize factorial
    

instead of:

    
    
      fast_factorial xs = (memoize factorial) xs
    

The key to point-free style is to think of all functions as potentially acting
like combinators, and being modifiers for other functions.

~~~
hristov
And where do you find the inferred type signature?

~~~
mbrubeck
I load the module into ghci and use the :t command. But I mostly do this
during development. This is the big reason that production-quality code should
generally have explicit type signatures for top-level functions.

~~~
hristov
Well this kind of proves my point. If you have to compile code simply to read
it, then the language is not very easy to read. What if you are reading the
code in order to debug it and the code cant compile?

And I know code should have type signatures but it often doesn't.

~~~
jrockway
_And I know code should have type signatures but it often doesn't._

Often? All the libraries in GHC have type signatures. All the libraries on
HackageDB I've used have type signatures. All the apps I've written have type
signatures. Even most Haskell blog posts (and wiki pages) use type signatures.

I think you should just peruse some production Haskell code, and try writing a
bit of your own. If you set aside your belief that everyone is out to confuse
you for a few minutes, I think you'll find that most Haskell is quite
readable, and quite writable. You'll see how other people compose functions,
what the idioms are, and then stuff like "sum = foldr1 (+)" won't confuse you
anymore. Instead, I think you'll see how you can read and write code more
quickly, and how to understand your program in terms of function application
instead of in terms of passing around boxes that hold data.

------
camccann
From the comments, an alternate form of the (.) . (.) operator:

    
    
      foo = fmap fmap fmap
    

Nothing says "welcome to Haskell!" like an inscrutable pile of fmaps. Oh,
pointless style, how beautiful you are.

In all seriousness, though, there are a lot of cases where a pointless--er,
"point-free"--style is actually clearer and more comprehensible, typically
when you're writing functions intended to be used as combinators. Similarly,
applicative style sometimes looks a lot cleaner than using do notation.

------
Tichy
I am not convinced

(.^) = (.) . (.)

is supposed to be more readable than

(.^) f g x y = f (g x y)

?

I don't know Haskell, but even so. I think there might be exercises with a
better benefit.

~~~
aerique
The former is definitely more suggestive.

~~~
Tichy
Programming in balance with Yin and Yan :-)

------
how_gauche
I often use this algorithm:

1\. write a function in pointed style 2\. run it through pointfree 3\. is it
shorter/easier to read? then use pointfree's definition

This is really a personal shortcoming though because after 20+ years of
writing code in "standard" languages my brain is sufficiently warped that I'm
not always able to think of the short and clear solution without "grinding the
gears".

