Yes, but for some reason people look at Forth postfix syntax as "reverse" or opposite to what they are used to, like driving on the "wrong" side of the road then compare Forth with the "novelty" of an RPN calculator
Here in Australia we are "down under" because the North pole is always positioned on top by way of convention, not because it is "up" by nature or science.
Which is more natural then? There have been many Forth CPU designs that run code such as OVER + SWAP natively instruction for instruction but you will never find a 'C' CPU, only one that is a bit friendlier for the C compiler writers.
But here we are digressing and going OT, my apologies to the OP.
A conventional compiler has to perform mutiple passes of the source code to "make sense of it" and break it down into efficient runtime code. In Forth the source does not need to be broken down, it is already in its most efficient form ready to run much like PASM. A benefit of this is that you know what is actually happening rather than scratching your head only to find out that the compiler needs whitespace or the braces in the right places
There's not one iota of truth in any of that. If you believe that Forth code cannot benefit from post-semantic analysis optimizations such as loop unrolling, invariant expression hoisting, common subexpression elimination and other back-end (multi-pass) optimizations, then you know nothing of compilation in the 1960s; read the Dragon Book.
If you believe that "conventional compilers", by which I believe you mean compilers for conventional languages, require multiple passes, then, again, you're simply wrong. There are myriad one-pass compilers for most languages - if you don't count linking as a second pass and linking is required for any of these languages including Forth.
Generally speaking generating optimized code for a stack-oriented p-code like either spin or forth is more difficult than for a register-based machine. Generating lousy code quickly is the hallmark of stack-oriented execution engines.
Remarkably, the Spin tools are inanely slow and generate horrid code - the worst of both worlds.
So you are quite adamant then that "there's not one iota of truth in any of that"?
Hmmm, putting aside one sense of "pass" as in rereading the whole complete source again I would find it hard for instance to imagine how optimizations are achieved but also in many languages even if they have strict rules for declarations that this doesn't always happen, a warning may be generated but the reference is resolved. So once these forward references are resolved then another "pass" is required although in some instances I know linking can be employed.
But my main point before you got so hot under the collar (for some reason) is not about specifics of other languages but that Forth itself and especially as in the case of small embedded systems such as the Prop, is that the source code is loaded in as a stream so compilation is strictly first-pass and line by line with no way to reread the source of even the current definition. It's about simplicity but also that Forth source is a very close one-to-one match for what is compiled and how that applies to Forth CPUs.
Sometimes I think I would like a little optimization such as when we might add an offset to a variable which is always calculated over and over again at runtime but unless the compiler is hosted on a PC there isn't much point or advantage in trying to optimize the one-pass compilation.
BTW, Spin has its limitations but in combination with PASM has proved very effective and is certainly appreciated, it got me started with the Propeller.
We have only a few ways of writing the same thing "3 + 9", "+ 3 9", "3 9 +". Let's not worry about writing vertically or wonder if adding 3 to 9 is the same as adding 9 to 3.
"+ 3 9" is Polish notation as far as I can tell. Named after it's origin, probably because nobody could pronounce Łukasiewicz So obviously "3 9 +" is reverse Polish.
Forth syntax is "reverse" in the in a more mundane way. It's somewhat opposite to how everyone learns their arithmetic and subsequent mathematical notation.
Forth does have this magical property that, devoid of any syntax, types, or any other useful language features, it is small and simple enough to bring up from scratch on very small machines. Is there any other language where that is simpler than a Forth like language?
Hey Heater, that was only one cents worth, where's the other one cents worth?
There are however far simpler languages of course, but none match Forth's low level access, speed, and high-level extensibility (and don't forget interactivity!). Anyway I think I've said before that you can think of Forth as the macroassembly language for a virtual CPU where Forth words are assembled more than compiled.
As for naturalness I may say "2 seconds" or "RED PEN" in Forth but another langauge may say "delayms(2000)" or PEN(#0xFF0000) as if enclosing everything in brackets were more natural, DING!
Comments
Here in Australia we are "down under" because the North pole is always positioned on top by way of convention, not because it is "up" by nature or science.
Which is more natural then? There have been many Forth CPU designs that run code such as OVER + SWAP natively instruction for instruction but you will never find a 'C' CPU, only one that is a bit friendlier for the C compiler writers.
But here we are digressing and going OT, my apologies to the OP.
There's not one iota of truth in any of that. If you believe that Forth code cannot benefit from post-semantic analysis optimizations such as loop unrolling, invariant expression hoisting, common subexpression elimination and other back-end (multi-pass) optimizations, then you know nothing of compilation in the 1960s; read the Dragon Book.
If you believe that "conventional compilers", by which I believe you mean compilers for conventional languages, require multiple passes, then, again, you're simply wrong. There are myriad one-pass compilers for most languages - if you don't count linking as a second pass and linking is required for any of these languages including Forth.
Generally speaking generating optimized code for a stack-oriented p-code like either spin or forth is more difficult than for a register-based machine. Generating lousy code quickly is the hallmark of stack-oriented execution engines.
Remarkably, the Spin tools are inanely slow and generate horrid code - the worst of both worlds.
So you are quite adamant then that "there's not one iota of truth in any of that"?
Hmmm, putting aside one sense of "pass" as in rereading the whole complete source again I would find it hard for instance to imagine how optimizations are achieved but also in many languages even if they have strict rules for declarations that this doesn't always happen, a warning may be generated but the reference is resolved. So once these forward references are resolved then another "pass" is required although in some instances I know linking can be employed.
But my main point before you got so hot under the collar (for some reason) is not about specifics of other languages but that Forth itself and especially as in the case of small embedded systems such as the Prop, is that the source code is loaded in as a stream so compilation is strictly first-pass and line by line with no way to reread the source of even the current definition. It's about simplicity but also that Forth source is a very close one-to-one match for what is compiled and how that applies to Forth CPUs.
Sometimes I think I would like a little optimization such as when we might add an offset to a variable which is always calculated over and over again at runtime but unless the compiler is hosted on a PC there isn't much point or advantage in trying to optimize the one-pass compilation.
BTW, Spin has its limitations but in combination with PASM has proved very effective and is certainly appreciated, it got me started with the Propeller.
Sorry Duane, we've gone OT again!
We have only a few ways of writing the same thing "3 + 9", "+ 3 9", "3 9 +". Let's not worry about writing vertically or wonder if adding 3 to 9 is the same as adding 9 to 3.
"+ 3 9" is Polish notation as far as I can tell. Named after it's origin, probably because nobody could pronounce Łukasiewicz
Forth syntax is "reverse" in the in a more mundane way. It's somewhat opposite to how everyone learns their arithmetic and subsequent mathematical notation.
Forth does have this magical property that, devoid of any syntax, types, or any other useful language features, it is small and simple enough to bring up from scratch on very small machines. Is there any other language where that is simpler than a Forth like language?
There are however far simpler languages of course, but none match Forth's low level access, speed, and high-level extensibility (and don't forget interactivity!). Anyway I think I've said before that you can think of Forth as the macroassembly language for a virtual CPU where Forth words are assembled more than compiled.
As for naturalness I may say "2 seconds" or "RED PEN" in Forth but another langauge may say "delayms(2000)" or PEN(#0xFF0000) as if enclosing everything in brackets were more natural, DING!
I'm wondering what languages simpler than Forth you have in mind.