Re: [stack] Why is point-free form so interesting?

Christopher Diggins <[email protected]> wrote:
> I have been struggling to formalize/rationalize my intuition that
> point-free form is somehow better than a form with names from the
> standpoint of tools (e.g. analyzers, compilers, translators,
> optimizers, etc.). Note: this is completely separate from any

Most of your points are good, but a few are specific to concatenative languages.

> - fewer evaluation rules (no alpha-conversion, no beta-conversion)

Just a side note: I think this one's the root of the coolness for
point-free languages. Because there are no parameter names, there's no
need for an approximate mathematical model of how the data gets from
the call site to where it's used in the function's body.

Digression: One of the few depressing things about reading SICP was,
to me, how hard a time they had explaining exactly how parameters
worked. If you haven't read SICP and you're interested in computer
science and languages, the best time to start reading it is a year
ago; the second best time is right now. http://mitpress.mit.edu/sicp/
(free online)

Anyhow, another result of point-free notation (implied by your point
about beta-conversion) is that because data isn't ever given different
names, there's no name change required when you inline or extract a
function. Your code is truly referentially transparent.

A positive result of dataflow notation (which I'm almost convinced is
the same thing as point-free notation -- I could be wrong) is that the
complexity of the dataflow is directly reflected in the complexity of
the code. Named data, on the other hand, can hide almost arbitrarily
complex dataflow. And dataflow directly impacts performance, if
nothing else by using resources like registers, cache lines, physical
memory, and paging. So clean-looking dataflow code is fast code.

> - flat structure versus tree
> - syntactic analysis can be performed on tokens rather than parse tree
> - fewer parantheses: all interesting computations are compositions,
> rather than applications.
> - rewriting rules are fundamentally easier (linear as opposed to trees)

These are all specific to concatenative languages (well, only *flat*
languages have them perfectly, but close enough).

> One question is: can we reasonably claim with any formality that a
> linear form is somehow easier to work with than a tree?

I don't see why not. It's a simpler data structure. It seems certain
that it should be "somehow" easier to work with. (Make that claim
stronger and I'll have to work harder proving it. ;-)

> Christopher

-Billy