When I read SICP, I worked through the exercises in Forth. I had to implement my own garbage collector, create dialect extensions for nice list notation, build a thunk-based mechanism for closure... with the right groundwork laid, Forth can keep up pretty well. I was always somewhat dissatisfied that cute metacircular lisp interpreters leave as tautologies so many important details of their own mechanics.

It functions as a good way to whet the appetite of the reader or student. SICP's meta-circular implementation occupies a kind of sweet spot, it imparts to students that only just grokked recursion to understand how the programming language itself is just a program they can understand and tinker with. The state machine implementation of the Scheme interpreter sort of breaks the meta-circularity to dismantle the tautologies.

How did you learn how to write your own Forth? Brodie shows how to just think in and use one already written right?

Jones Forth is an extremely readable tutorial how to write a Forth.

I've gone through it before, but it has been ages. Maybe I'll check again...thanks.

You're not the only one to observe this. It was observed and explored by Manfred von Thun with Joy, a purely functional programming language based on Forth. Modern "concatenative" languages continue this tradition:

https://en.wikipedia.org/wiki/Concatenative_programming_lang...

I've been working with Joy for a few years now and I have to say that it seems to me to combine the best parts of Forth and Lisp.

It's ridiculously elegant.

Do you have a link to whatever project you are working on? I'm interested in Joy but not aware of anyone working on or with it in recent decades.

Sure! I developed an interpreter for Joy in Continuation-Passing Style in Python: http://joypy.osdn.io/

I had just implemented type inference[1] when I got smashed over the brain by Prolog. So now the Python code is in limbo because the Prolog implementation of Joy is blindingly elegant[2].

In Prolog, the Joy interpreter is also the Joy type inferencer.[2]

The compiler (from Joy expressions to new Prolog rules) is five lines long.[2]

[1] http://joypy.osdn.io/notebooks/Types.html

[2] https://osdn.net/projects/joypy/scm/hg/Joypy/blobs/tip/thun/...

Thanks!

Yes, there's a real connection between concatinative languages and logic languages. In some sense you can think of a concatinative logic language as Joy with the ability to push "unknown" values onto the stack, as well as a few constraint manipulatives. That's somewhat orthogonal, but it makes sense an interpreter for Joy would be quite compact in prolog.

Thanks for the links, I'll review your work later!

Cheers!

You might also like: http://conal.net/papers/compiling-to-categories/

He transforms Haskell to a point-free form that's suspiciously like Joy... ;-)

> It's fascinating the relationship between Lisp and Forth.

Is there more to the relationship than "Lisp is written as a preorder tree, and Forth is written as a postorder tree"?

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.

Starting Forth by Leo Brodie is a classic book. Forth is a very elegant language. I came across a javascript implementation of it recently, which you can look up yourself :)

As a kid I went from basic to assembly. When I was shown Forth by my dad's friend I was totally caught up in Forth on my C64. I later tried Pascal which is also great but it wasn't close to forth in my mind. It was awesome Except you had to pay for the language and I am guessing that is why it died.

Currently my preferred language is Racket because it is so fun and practical, reminds me of the earlier days of Python but much more thought out. You write you code (which is fun) and you have an executable all within one setting.

Armed with that and a copy of Threaded Interpretive Languages by Loeliger (How I found out about the book is beyond me) from the library I managed to put together a complete(ish) Forth for the Apple ][ running ProDOS.

I think the magic bit with Forth is that it's easy to see how to write one by the time you've finished Starting Forth.

Is it though? Man, maybe I'm dumb :)

I wish there was an easy checklist: Create stack data structure, create return stack, create primitives ...etc.

What does Factor have to do with my question? Yes it's a concatenative language that is still maintained although Slava left. I'm guessing it wouldn't make a great example if you're suggesting going through source.

And it seems to be free for personal use: https://www.forth.com/starting-forth/