That was me.

I wrote a FORTH in 6809 assembly for the TRS-80 Color Computer running this OS

https://en.wikipedia.org/wiki/OS-9

which was very much UNIX influenced and could support three users logged in simultaneously. I wrote to the Forth Interest Group and got back a reference card for the standard and used that for a guide. The big thing I did differently was file I/O; at that point in time FORTHs often accessed individual blocks on the disk, your code editor would edit one block at a time, etc. If you already have an OS, text editor and such it makes more sense to provide an API similar to the C API for the filesystem so that's what I did and the standard caught up.

I used to do FORTH. I still do, but I used to, too.

"Upward funargs" is where you return a closure which captures the bindings of your local variables, so it can access arguments from an outer scope which no longer exists. Like this:

    scheme@(guile-user)> (define (make-adder x) (lambda (y) (+ x y)))                                                 
    scheme@(guile-user)> (define x+3 (make-adder 3))
    scheme@(guile-user)> (define x+4 (make-adder 4))
    scheme@(guile-user)> (x+3 7)
    $1 = 10
    scheme@(guile-user)> (x+4 8)
    $2 = 12

    scheme@(guile-user)> (define (counter n) (lambda () (set! n (1+ n)) n))
    scheme@(guile-user)> (define booga (counter 53))
    scheme@(guile-user)> (booga)
    $3 = 54
    scheme@(guile-user)> (booga)
    $4 = 55

Upward funargs generally require a non-stack-like allocation discipline for the local-variable bindings.

While implicit variable capture like Scheme is the most common way to do closures, it isn't the only way; C++ and old versions of Python (before nested_scopes) have a form of closures where you instead explicitly list the variables you want to capture. Old dynamically-scoped Lisps like Lisp 1.5 had a different solution which I don't understand; see AI memo AIM-199, "The function of FUNCTION in LISP".

Usually dynamic scoping is incompatible with tail-call elimination (except in the special case of tail recursion) because you can't eliminate a tail call if which you have more work to do after it returns; usually popping some variable bindings off a context stack amounts to "more work to do". Maybe your parameter stack has a way for that to happen implicitly, for example by implicitly restoring a parameter-stack offset on function return.

I hope this helps. Keep being awesome!

Can you write a ZMachine interpreter?

Back in the day there was ITS, Maclisp and Emacs on top of TECO.

Most of this ”technology” was created at the MIT AI Labs,

Genera did a few cool things but in the grand scheme of things it is essentially not much (the Dynamic Listener probably being the most interesting thing, the rest of the system was essentially the same).

The MIT version of the Lisp Machine is free software without any legal conundrums. So there you go …

The Symbolics intellectual property wasn't a legal minefield until the past decade and change, where it was acquired from Andrew Topping's estate by a longtime MIT Lisp guy who has been a complete idiot for not opening it up to the world.

However, he only actually owns it if Andrew Topping actually paid the Symbolics bankruptcy executor for it in full. (Not doing so would entirely fit Topping's character, based on his criminal rap sheet.) If Topping didn't fully pay for it, then it still belongs to whoever or whatever the successor of the Symbolics bankruptcy executor is; I think that was ABN AMRO.

Good luck finding any of that out!

Let's take Laxen and Perry's F83 implementation as an example.

F83 implements an assembler, a memory hex dumper, an interpreter, a sort of bytecode compiler, a decompiler, a single-stepping source-level debugger, a screen editor (which could jump to the definition of any function and jump back and forth between source and documentation, and which tagged each screen of source code with the last edit date and author's initials), cooperative multitasking with thread-local data, a print spooler, and virtual memory. It can also compile programs into standalone executables, and in fact it's written in itself, so it can cross-compile itself for other architectures and operating systems; it supported CP/M-86, MS-DOS, and CP/M for the 68000.

The Forth programming language it implements is low-level but relatively powerful; among other things, it includes structured control flow, Turing-complete compile-time macros, closures, pointers, and multiple return values.

This is nothing unusual for a Lisp system, of course. What is different is that F83 is only about 2100 lines of code by my count. That's what makes it "more moldable" than a Lisp system with the same features, which would require around an order of magnitude more code.

There are some major compromises made in pursuit of this level of minimality, though: no type-safety (not even to the extent of calling functions with the right number of arguments), no built-in structs (though you can build them with its macro system and closures), no bounds-checking on arrays, error-prone manual access to the virtual-memory system, no syntax, no stack-allocated named variables, etc.

Probably because Lisp requires a GC. With Forth you have to write your code to fit a finite memory footprint.

Ask Don Hopkins:

https://news.ycombinator.com/user?id=DonHopkins

I remember it as, "YOU FORTH LOVE IF HONK THEN"

This link I found seems to corroborate

http://www.drdobbs.com/blog/archives/2010/09/forth_love_if_h...

but the Wayback Machine is down so I can't check.

On reflection I think you are correct. Admittedly I have not done anything with Forth in quite some time.

I don't know about kicking, it's not exactly thriving.

I prefer Lisp for tricky problem solving, but it's unfortunately a no go professionally outside of prototyping ideas.