> Forth has no (well, very little) runtime error checking.
I don't think the standard prevents you from implementing that. If you want it, do it.
> The language is [WEAKLY] typed. It just doesn't have any type checking
True. However, a linter that does some type checking seems possible, provided some annotation syntax for the hard cases where it's not possible to infer types.
The thing is, despite its long existence one doesn't see many "Lint for Forth" around, so we can guess people managed to solve this problem in a different way.
> So you're now mentally juggling three different stacks: the data stack, the return stack, and the compiler stack, and if you make a mistake anywhere you're going to have a bad day.
The "compiler stack" is never an issue unless you overuse the "metaprogramming" capabilities of Forth like you'd abuse macros in Lisp.
I understand you might have had that impression if you spent more time implementing the interpreter than implementing programs.
> There's a lot of trivia to remember, which you need to remember. EXIT is allowed inside a BEGIN..AGAIN loop. But it's not allowed inside a DO..LOOP loop
Well of course you're supposed to know that the loop index is stored on the return stack. For a Forth programmer, it's as trivial and obvious as taking care of freeing malloc'ed memory is for a C programmer.
> There's no scope for, e.g., running out of heap and allocating another block from the operating system. Oh, and try not to run out of memory, because it will etc.
That's because it's typically not needed for various reasons. However if you really need it you can:
- make all of your addresses relative so that your system can reallocate the dictionary space; in other words, make your VM run Place Independent Code (PIC).
- create a library that allows you to allocate memory from the OS or the heap.
> Stack juggling gets old very, very quickly. (Although some Forths, not mine, support local variables.)
It's like saying FP is a hoax because you use mutability all the time. The problem is not in the language, it's how you use the language.
> While back I wrote a Forth interpreter. I recommend this to anybody interested in programming languages; you don't have to finish it
You should really finish and actually use it because you don't understand Forth yet.
Oh, and don't be afraid to discard standard compliance. It's a bad trade for you: you get all the constrains and will probably never benefit from the advantages.
I don't think the standard prevents you from implementing that. If you want it, do it.
> The language is [WEAKLY] typed. It just doesn't have any type checking
True. However, a linter that does some type checking seems possible, provided some annotation syntax for the hard cases where it's not possible to infer types. The thing is, despite its long existence one doesn't see many "Lint for Forth" around, so we can guess people managed to solve this problem in a different way.
> So you're now mentally juggling three different stacks: the data stack, the return stack, and the compiler stack, and if you make a mistake anywhere you're going to have a bad day.
The "compiler stack" is never an issue unless you overuse the "metaprogramming" capabilities of Forth like you'd abuse macros in Lisp. I understand you might have had that impression if you spent more time implementing the interpreter than implementing programs.
> There's a lot of trivia to remember, which you need to remember. EXIT is allowed inside a BEGIN..AGAIN loop. But it's not allowed inside a DO..LOOP loop
Well of course you're supposed to know that the loop index is stored on the return stack. For a Forth programmer, it's as trivial and obvious as taking care of freeing malloc'ed memory is for a C programmer.
> There's no scope for, e.g., running out of heap and allocating another block from the operating system. Oh, and try not to run out of memory, because it will etc.
That's because it's typically not needed for various reasons. However if you really need it you can: - make all of your addresses relative so that your system can reallocate the dictionary space; in other words, make your VM run Place Independent Code (PIC). - create a library that allows you to allocate memory from the OS or the heap.
> Stack juggling gets old very, very quickly. (Although some Forths, not mine, support local variables.)
It's like saying FP is a hoax because you use mutability all the time. The problem is not in the language, it's how you use the language.
> While back I wrote a Forth interpreter. I recommend this to anybody interested in programming languages; you don't have to finish it
You should really finish and actually use it because you don't understand Forth yet.
Oh, and don't be afraid to discard standard compliance. It's a bad trade for you: you get all the constrains and will probably never benefit from the advantages.