> GreenArrays use manycore chips based on a processor array approach. So they're using a FORTH-like stack machine on the individual cores, running serial code and not addressing much memory - but that still leaves open the problem of programming the system as a whole.
My guy, do you really think that no one at GreenArrays ever thought, "Gosh, it would be nice to have some way to coordinate all these parallel processes..." You really think you're the first one to think that? Geez.
Hint: it's coroutines. Like I said, not that different from the way and how the rest of the industry works, though it's notable that colorForth was ahead of the industry in this respect.
> But the FORTH community thinks of it as a high-level language, not just as a machine target.
Please refrain from telling me what I think. You might say that I don't speak for the entire Forth community, and that's true, but neither do you.
I don't think of it as either a high level language or a machine target.
The homogeneous nature of the instructions all operating on the stack lets you do some higher level stuff, similar to the homogeneous nature of Lisp operating on lists enabling higher-level stuff. The parallels between Forth and Lisp aren't surface-level, either: it's trivial to see the conversion between "(+ 1 2)" in Lisp and "1 2 +" in Forth, but it might be less obvious that these have the same effect on the stack in a simple implementation of both languages. Where they differ is that Lisp leans into the higher level features and focuses on maintaining purity while abstracting away stack operations, while Forth makes the stack explicit and focuses on maintaining direct access to processor instructions, and breaks functional purity with operations like dup. This is why I'd say forth is a lot closer to an assembly language than a high level language, even if it's capable of some high-level constructions.