> I wouldn't call people stupid I don't think I did such a thing. > Do you have any concrete [proof] that the Forth implementation with compile-only words is

> I wouldn't call people stupid I don't think I did such a thing. > Do you have any concrete [proof] that the Forth implementation with compile-only words is better? What are its benefits? Yes I do : a Smalltalk-style forces to have the code (to be executed if the condition is true) to be on the left side of the if. Additionally, if you don't want the address of the quotation to be in your way, you are also forced to adopt an argument order like condition-quotation-if, which is even less convenient than Forth's syntax. Oh, and the else part could be a lot of fun too. Most likely, you'll add some sort of exception to avoid all that, but exceptions are the archetype of unwanted complexity. You seem to think that Smalltalk-style is simpler, but Smalltalk is an infix language with, granted, rules that are simpler than most other languages - but still more complex than those of Forth. So it is not, actually, simpler when you consider the system as a whole. Also, it makes it more difficult to build loops from that if and recursion like Scheme does (TCO). Chuck Moore's Colorforth does exactly that. Moreover, and perhaps more anecdotally because few people care about this these days, it is more space and CPU efficient - basically the traditional Forth if is one instruction (bytecode or whatever) followed by one parameter (the jump target) that takes one argument on the stack. A Smalltalk-style if is also one instruction, but it has to call the "if-true" code, and this code has to have a return instruction as well. I can understand that people don't care about a few more bytes and cycles here and there - what's the point for a interpreter to be able to run on a bunch of kilobytes today? - but I wonder why those same people would care about a weird RPN thing that seems to be designed to make their head hurt, with or without quotations. It's only slightly less hostile for them than BrainFuck. Computer games and computer languages have something in common: when you design and redesign them, you realize that they are a subtle network of interactions between different parts of the system - even if, in the case of programming languages you look for "orthogonality", which is the opposite; but this concept applies more to features/semantics than to syntax/ergonomics. > The problem is already solved. You just spit out a warning message when something is redefined instead of an error. You didn't get what I wrote. You want the system to keep quiet when you give an hint that you do something on purpose, like casting explicitly an integer into a pointer in C. You also miss the point: of course this problem is easily solved. But I argue like Chuck Moore that you'd rather solve the specific problem you stumble upon in practice, rather than trying to solve the more general problem that you imagine you will have. Sometimes when you try to kill two birds with one stone, you end up with one bird wounded and a broken window.