> For instance, suppose we push 200 operands onto the stack (o1 o2 o3, ...), Nobody does that. That's a meaningless example. Most systems don't have stacks tha

> For instance, suppose we push 200 operands onto the stack (o1 o2 o3, ...), Nobody does that. That's a meaningless example. Most systems don't have stacks that deep anyway. This is not Forth. It's pointless to reason on things you definitely don't do in Forth because everyone knows it will fail. It's like arguing against C because you can forcefully cast an integer into a pointer and make a function that expects a pointer to crash the system. Well, duh. Don't do that, as we often say in the Forth community. Probably the first thing Forth newcomers have to learn is stop doing things that maybe are the right way in some other language they come from, but are definitely wrong in Forth. Don't do that, and you will have one less problem. The best way to solve problems is to avoid them entirely. That's a precious lesson Forth teaches you, sometimes the hard way. > In a language with syntax The whole idea of Forth is to stop relying on these things. This is probably the main part of Forth training: stop doing things in such ways that the only viable option is to rely on syntax, type checking and other crutches. Forth programmers have been doing things without them for 40 years. This is where Forth is a paradigm shift, and it seems that many people don't realize it. They usually claim it is a defect that needs to be fixed, but it is actually a feature.