Thank for that pdf, reading it right now. Having a bit of Forth experience probably helps tremendously in reading it.

I noticed the 'pipeline' vs 'function call' equivalence a couple of months ago and I'm still working out all the implications of it.

It may be that stack oriented languages and functional languages are a lot closer to each other conceptually than you'd normally think they are and I think the pdf you linked here illustrates that nicely.

Also there is some equivalence between a process pipeline and either of these two. (for instance 'cat file.txt | grep x | wc').

Even if it uses a series of inter-process communication the effect is much the same. In factor that you could code up words for 'cat', 'grep' and 'wc' and then it would probably look something like this:

  :cat (filename -- lines) ascii file-lines;

  "file.txt" cat
  x grep
  wc

Not sure if that's exactly correct but it seems a trivial expansion of the example in the pdf, more complicated pipelines would simply require more steps but the principle remains.

stack oriented languages and functional languages are a lot closer to each other conceptually than you'd normally think they are

Yes. In fact, here’s something to think about.

Imagine a dialect of lisp where every function takes a known number of arguments. You could hard-code this per function, for example saying that + always takes exactly 2, or you could do it by keyword args, or you could make every function take a quoted list, or maybe some other ways.

In this lisp dialect, parentheses would be superfluous (except to specify quoted lists).

If you wrote it backwards, it would be a forth.

For example, let’s say * and + take exactly 2 args each.

    (* 3 (+ 1 2)) ; lisp
    * 3 + 1 2     ; trivial variation if arity is always known
    2 1 + 3 *     ; valid in almost every forth dialect, RPN calculators, etc.

Likewise, it would be ugly, but we could imagine a shell-like language that used dash-flags for all args such that you never had to make a pipe explicit:

    cat --file=foo sort -n head

Instead of:

    cat foo | sort -n | head

If you wrote this backwards, it would basically be an ugly forth dialect with keyword args.

Basically, if you don’t use assignment, you can chain things up however you please. If your syntax chains in one direction, you’re arguably writing some kind of bastardized lisp; if it goes the other way, it’s arguably a forth dialect. This is why I capitalize Perl and Python but not forth and lisp ;).

there is one huge advantage to the 'forth' way of doing things, you can start processing left-to-right as you read in the data. This makes it possible to stick a forth 'processor' on the other end of a wire and to parse / run the code as it gets pushed down the wire without needing backing store the size of every possible input.

For a 'lisp' like structure you'd need at a minimum enough storage to get all the way to the innermost expression before you can start to interpret the data.

Normally not much of a problem, but if you were to make a fabric that consists of little processors stuck together with comms wires the forth way of doing it could be an advantage.

When you're done with that you should also read through the examples John Benediktsson's been posting to his blog: http://re-factor.blogspot.com