[djmips]

Hard reasons.

Forth implementations on the 6502 uses a stack and require more RAM than Co2 which uses a compiled stack.

I feel like Co2 would compile to faster code but of course I haven't benchmarked this. The reason I feel this is so is that I way I understand compiled forth is that the 'words' are still threaded so you don't escape the interpreter overhead.

Soft reasons.

Co2 takes away the chore of parsing, in Forth you are the parser. It's simpler but more error prone and harder to read (subjectively).

Forth is postfix notation which for a lot of people is challenging.

[asguy]

> Forth implementations on the 6502 uses a stack and require more RAM than Co2 which uses a compiled stack.

I don't know what you mean when you say this. Could you elaborate? Any function call is going to require putting the arguments somewhere.

> The reason I feel this is so is that I way I understand compiled forth is that the 'words' are still threaded so you don't escape the interpreter overhead.

Indirect/direct threading at runtime isn't required; it's up to the compiler. There are plenty of Forth cross-compilers (e.g. MPE's) that compile native code (and call it "subroutine threaded"). They don't have an explicit (inner) interpreter... they just use standard CPU opcodes to call/return.

[saagarjha]

> I don't know what you mean when you say this. Could you elaborate? Any function call is going to require putting the arguments somewhere.

There's a footnote in the article that might be helpful:

> this is thanks to a "compiled stack", a concept that's used in embedded programming, though I had a hard time finding much literature about it. In short, build the entire call graph of your project, sort from leaf nodes to roots, assign to each node memory equal to it's needs + the max(children)