This may seem really obvious to the FP cognoscenti here, but what is point free style in Scala good for? What would really sell me on the topic is an illustration that shows how point free style is significantly better in some dimension (e.g. performance, elegance, extensibility, maintainability) than code solving the same problem in non-point free style.
-
4Hmm, actually, for more than trivial examples, Scala is not the best language to use for point-free programming. At some point either the type inferencer will nag you and request hard facts about the types you want to use or the implicit evaluation of methods (which you then have to turn into functions with `_`) makes it rather doubtful whether the result can really be called ‘point-free’. – Debilski Jul 25 '11 at 11:21
4 Answers
Quite simply, it's about being able to avoid specifying a name where none is needed, consider a trivial example:
List("a","b","c") foreach println
In this case, foreach
is looking to accept String => Unit
, a function that accepts a String and returns Unit (essentially, that there's no usable return and it works purely through side effect)
There's no need to bind a name here to each String instance that's passed to println
. Arguably, it just makes the code more verbose to do so:
List("a","b","c") foreach {println(_)}
Or even
List("a","b","c") foreach {s => println(s)}
Personally, when I see code that isn't written in point-free style, I take it as an indicator that the bound name may be used twice, or that it has some significance in documenting the code. Likewise, I see point-free style as a sign that I can reason about the code more simply.

- 49,540
- 9
- 105
- 155
-
I do generally see the benefit of using point-free style as illustrated in your example, but probably I should have said I was looking for a "non-trivial" illustration. In your example, non-point-free style is only slightly more verbose, IMO not enough to show that point-free really makes a dramatic difference. – enhanced_null Jul 25 '11 at 09:48
-
Again, this is arguable, but the benefits only multiply with more complex examples. In many cases, eliminating braces/parenthesis and underscores can reduce the number of levels of nesting you have to consider when reading a piece of code. Of course, I can also find counter-examples, what really matters to me is whether of not adding a name for the "point" makes it more self-documenting. – Kevin Wright Jul 25 '11 at 14:10
-
-
The place where point-free style is most beneficial in Scala is function definition + function composition, I think. Lets you omit named parameters entirely and concentrate entirely on the composition of functions. If you have 3 functions which take a Seq and return a Seq then `do123: Seq[A] => Seq[A] = f1 andThen f2 andThen f3` is simpler and more expressive. However, that only works well with composition of functions, not methods. As soon as methods are mixed in, it becomes uglier. – itsbruce Sep 08 '15 at 12:21
-
2Isn't pointfree programming about programming by composing functions together instead of tying them to objects: `val squareList = map square` could be a representation, does Scala support this representation. An example from Learn you a Haskell looks like: `listFn = map (negate . sum . tail)` – vamsiampolu Nov 28 '17 at 05:48
-
1An explanation of pointfree style is provided here http://www.scala-lang.org/old/node/9371.html – vamsiampolu Nov 28 '17 at 05:55
-
1@vamsiampolu what I came here to figure out as well, looks like you can define your own but doesn't look like the scala community drinks from this cool-aid yet: ```def map[A, B]: (A => B) => Iterable[A] => Iterable[B] = f => list => list.map(f) def always[A, B]: A => B => A = x => y => x val dingoMap = map(always("dingo")) dingoMap(List(1, 2, 3)) // -> List("dingo", "dingo", "dingo") ``` – AndrogenAgonist Apr 01 '21 at 22:47
One appeal of point-free style in general is that without a bunch of "points" (values as opposed to functions) floating around, which must be repeated in several places to thread them through the computation, there are fewer opportunities to make a mistake, e.g. when typing a variable's name.
However, the advantages of point-free are quickly counterbalanced in Scala by its meagre ability to infer types, a fact which is exacerbated by point-free code because "points" serve as clues to the type inferencer. In Haskell, with its almost-complete type inferencing, this is usually not an issue.

- 30,818
- 8
- 72
- 90
-
Yes, point-free style would help you avoid coding errors like using the wrong loop variable. OTOH, such errors are usually not that hard to spot. – enhanced_null Jul 25 '11 at 09:56
I see no other advantage than "elegance": It's a little bit shorter, and may be more readable. It allows to reason about functions as entities, without going mentally a "level deeper" to function application, but of course you need getting used to it first.
I don't know any example where performance improves by using it (maybe it gets worse in cases where you end up with a function when a method would be sufficient).

- 54,104
- 13
- 100
- 195
Scala's point-free syntax is part of the magic Scala operators-which-are-really-functions. Even the most basic operators are functions:
For example:
val x = 1
val y = x + 1
...is the same as...
val x = 1
val y = x.+(1)
...but of course, the point-free style reads more naturally (the plus appears to be an operator).

- 7,187
- 4
- 44
- 44
-
3Appologies, I didn't realise there was a non-obvious meaning to "point-free." Perhaps you can explain what you mean by "point-free" to avoid future confusion? – Jim Hurne Jul 25 '11 at 23:36
-
5In short, it means leaving out explicit references to a function’s arguments or defining a function with functions only. A bit hard to explain in a comment. (http://stackoverflow.com/questions/944446/what-is-point-free-style-in-functional-programming / http://en.wikipedia.org/wiki/Tacit_programming) – Debilski Jul 26 '11 at 00:02
-
4Thank you for your misunderstanding, because it had been mine as well and to be persistent in the dialog which aimed in some useful links. :-) – Lutz Jul 29 '11 at 15:35