Why Concatenative Programming Matters

The problem with stack languages for me has always been in typing. I find it difficult to track the exact stack effects of each word (function), particularly if these functions are pushing, popping and applying functions that themselves modify the stack. Even when dealing with something as simple as optimized x87 code, I would annotate all the FXCH etc. to keep track of the bits of the arithmetic expression on the stack, as I tried to keep multiple operations in…

The ergonomic drawback of concatenative languages is that when you see `a b c d e`, you don’t know whether it means `e(d(c(b(a))))`, or `e(b(a), d(c))`, or `e(a, b, c, d)`, or `b(a), e(c, d)`, etc. The answer depends on the types of a, b, c, d, and e. The syntax `a b c d e` is a linearization of the call tree, whose node structure can be recovered from the types of the symbols (assuming the language is statically…

Long, long ago I wrote a Forth of OS/2 out of spite. I've had a long standing interest in the language. It's been my opinion for a while that Forth is a less powerful language than LISP, even though they initially appear to just be the opposites of each other in terms of argument handling. The thing that makes Forth and other similar languages write-only is that you can easily lose track of the variables when you are forced to…

> A concatenative programming language is a point-free programming language in which all expressions denote functions and the juxtaposition of expressions denotes function composition. The combination of a compositional semantics with a syntax that mirrors such a semantics makes concatenative languages highly amenable to algebraic manipulation. This is the reason i hate so many (not all) wikipedia articles - the introduction is an exercise of code golf in human language. This is devoid of the key quality most…