Why Concatenative Programming Matters (2012)

The elegant minimalism of Forth is inspiring-- how many other languages can fit their REPL and development environment into a few kilobytes?

However, I find implicit arity to be the largest barrier in reading concatenative programs.

To understand what a line of Forth code does, you need to understand both what each function does, and how it manipulates the stack to accomplish it. That's more memory pressure than an imperative language like C, where the flow of data and computations is obvious. It's exacerbated by the tendency to factor a single function into many simpler ones.

In a team, the increased memory burden also requires more communication for shared understanding of code.

Many concatenative languages eventually grow support for local variables, since it's _incredibly_ awkward to implement certain algorithms when you have to do stack juggling to use a variable in a computation.

This is true, but it’s also important to realise that Forth is not the only direction. ;)

It’s been a while since I wrote this article, and there are a number of things it doesn’t address, such as the practical concerns you mention. It’s much the same issue as comes up when dealing with large assembly projects, or dynamically typed ones for that matter. Knowing what’s going on can be difficult to discern without a deep understanding of the overall system, and bugs have a tendency to hide in obscure places.

And speaking of assembly, Forth is essentially assembly code for a virtual stack machine. Or an actual stack machine.

I’ve been idly working on a statically typed concatenative language for a long time now, partly because I intend it to be taken seriously sometime in the next decade, but mostly as a learning experience. It’s designed to address many of these concerns—particularly, enabling programmers to focus on data flow by framing it as a functional language. (E.g.: don’t shuffle stacks—use combinators and/or locals.)

However, I continually run into problems with the type system. Typing of concatenative languages is not well researched and is surprisingly difficult. I’m not a type theorist by any means, but at this point I’m probably the world expert on concatenative type systems, simply because there are so few people working on the problem. If anyone would like to help out, I’d love to chat by email (username@gmail).

I might be wrong, but I think a concatenative language can’t be represented using only arrows, because arrows aren’t sufficient to express dynamic function application. You can think of monads as arrows with the “bind” function of a type like (a × (a → b) → b). That’s precisely the type of the common concatenative “apply” combinator that lets you do anything useful. The lifting of application is what allows you to treat terms (objects) as actions (morphisms). Without it or an equivalent combinator, you can’t write context-sensitive computations or manipulate concatenative quotations in any meaningful way.

Forth is brilliant, but my favourite concatenative language is PostScript. Most view PostScript as nothing more than a dated binary format for vector graphics. However, writing plots and diagrams in pure PS is incredibly flexible and pretty easy once you build up or find enough libraries to do what you want. Postscriptbarcode[0] is an example of a good library. [1] is a good guide to writing PS by hand.

What is PS does lack, however, is a modern debugger (or interpreter with decent error reporting) and package management.

[0] http://code.google.com/p/postscriptbarcode/ [1] http://www.math.ubc.ca/~cass/graphics/manual/

Cat is concatenative and statically-typed. http://www.cat-language.com/