When Does Point-Free Notation Make Code More Readable?

Re:When Does Point-Free Notation Make Code More Readable? by pacala on Friday September 29, 2017 @10:27AM (#15365542)

Using a good function syntax [Scala], the pointed version is:

    { x => Math.pow(2, x) }

Obvious it's a function of 1 argument. The pointfree variant requires 1 extra concept [partial], plus building a mental map of the arguments, to reconstruct what kind of a function [or value!] the pointfree expression represent.

Furthermore, implementing the reverse check is syntactically symmetric in the pointed version:

   { x => Math.pow(x, 2) }

Whereas the pointfree version, assuming the function is not commutative, accumulates even more concepts:

   partial(flip(Math.pow), 2)

[ Parent | on HN ]

Re:When Does Point-Free Notation Make Code More Readable? by mrkgnao on Friday September 29, 2017 @10:33AM (#15365595)

Using even better (PureScript) syntax, the pointfree version of the latter can be written in notation similar to a hom-functor.

   f1 = pow 2
   f2 = pow _ 2

This makes it look like a lambda but without having to bind an argument explicitly. Makes it much nicer to write complicated expressions (although I can't speak to the readability for people less fluent in the syntax).

[ Parent | on HN ]

Re:When Does Point-Free Notation Make Code More Readable? by pacala on Friday September 29, 2017 @10:37AM (#15365643)

You still have to remember that pow has 2 args, and not 1 or 3, to get a basic sense of what kind of object f1 is. How about:

   f1 x = pow 2 x
   f2 x = pow x 2

[ Parent | on HN ]

Re:When Does Point-Free Notation Make Code More Readable? by moomin on Friday September 29, 2017 @10:55AM (#15365820)

Kind of irrelevant in a language that has type declarations on the previous line.

[ Parent | on HN ]