There is an ancestral relationship. Chuck Moore studied under McCarthy directly.

Yep. And back in the 1970's Chuck Moore wrote a book describing the implementation and design of FORTH, and it is pretty close to LISP. And I asked Chuck Moore directly, in person, if there was a connection to LISP, and he said "yes".

They are both very different, technically, but culturally they are very similar. Both of them are extremely simple and build complex programs from a few fundamental principles. Both of them are disengaged from the more mainstream languages. Both of them broaden your perspectives as a programmer. Both of them have excellent books that were written a long time ago but are still relevant today. Both of them gave rise to specialized hardware (stack computers and Lisp machines). Both of them encourage you to write your own interpreter when you are learning them... Although both languages are very different, learning one or the other actually is a quite similar experience.

Forth is actually disengaged from mainstream languages; Lisp being disengaged from mainstream languages is just a meme believed by some non-Lisp programmers (something to do with those parentheses). Basic Lisp is very similar to mainstream languages in the Algol family. Lisp dialects usually have nested block structure, with local variables that can be assigned, functions with formal parameters with ordinary by-value argument passing and so on. Javascript is a mainstream language and has strong ties to Lisp, much more so than to Forth. Python is more closely related to Lisp than to Forth. C is more closely related to Lisp than to Forth. Java is more closely related to Lisp than to Forth ....

Short answer: no.

Longer answer: actually another common feature is that both can execute code at compile-time (macros).

Full answer: really, no. They are fundamentally different: Lisp is a decent symbolic language, Forth is a decent portable assembler.

Really, no. They are fundamentally identical executable lambda calculus, despite Lisp's attempts to look abstract by shrouding itself in parentheses and Forth's attempts to look like "portable assembler" by exposing most implementation details.

Forth isn't written as a tree; the tree structure in the evaluation/compilation comes from the semantics of the words (how many elements of the value stack they consume).

In Lisp we know that (eql 1 2 3) is a "too many arguments" error. It doesn't just take 1 2 from the stack, push back the answer, and leave 3 beneath it.

Lisps are actually fairly conventional block-structured languages, having more in common with Pascal than with Forth. Lexical scopes, local variables, function calls with arguments going to formal parameters and all that.

> In Lisp we know that (eql 1 2 3) is a "too many arguments" error. It doesn't just take 1 2 from the stack, push back the answer, and leave 3 beneath it.

That error also comes from the semantics. You can't tell that (eql 1 2 3) is a too-many-arguments error just by looking at the tokens. That could be a 3-ary function, or an "eql is not a function" error.

The parentheses in Lisp code certainly suggest a particular tree structure, but they don't require it by virtue of their graphical form. And once you're willing to look up the arity of functions, Forth is written directly in its own tree structure to exactly the same degree that Lisp is, just with structural markers elided.

Think about it another way: a classmate in compilers class asked me once how Lisp handled operator precedence. Obviously, with the tree structure of the code fully specified, Lisp doesn't handle operator precedence because the question can't arise.

Note that this is just as true of Forth.

We can tell that 3 arguments are being applied to eql from that expression; when this is compiled, the generated call will pass 3 arguments, regardless of whether eql likes that, or whether such a function even exists. In the absence of any static checks, it will have to be caught at run time; but it will be caught.

Also, Lisp supports variadic functions with the same safety. Delimitation of arguments is necessary for variadic functions, like list.

The structure of every top-level form is an actual tree object in memory that is constructed before anything else happens. It can be walked by macros, or quoted so that the program accesses it as data directly.

Basically, nothing like Forth.

> Delimitation of arguments is necessary for variadic functions, like list.

This is not the case; you can easily have a Forth word that consumes however many arguments as are on the stack.

Ah, but the argument was made that Forth code has an implicit tree structure based on looking up the arity of functions, in place of explicit delimitation with parentheses. How can that be if some function takes N arguments, where N is, say, a run-time value, itself on the stack.