4 ms·

> Forth routines are usually short so they don't need local variables. Variables have to go somewhere. In a zero operand machine they go on the stack. Good l

by dewster 10y ago

> Forth routines are usually short so they don't need local variables. Variables have to go somewhere. In a zero operand machine they go on the stack. Good luck finding them amidst all the confusing rolling, picking, duping, etc. > Why? Because the ALU is just laying there doing nothing while the stack is having it's spine manipulated (see above).

astrobe_ 10y ago
> Variables have to go somewhere. Good luck finding them amidst all the confusing rolling, picking, duping, etc. Of course you don't want to use roll or pick. That's tutorial-level knowledge that you shouldn't use them. What you do when you see that coming is that you offload something to a global variable. The "something" is often the central topic of some part of the program, like a file handle for instance. So it makes sense to put it in a variable because it's needed in many places.
- progman 10y ago
  > Of course you don't want to use roll or pick. That's tutorial-level knowledge that you shouldn't use them. I think the opposite is true. Basic, Assembler and Forth were my first languages. Forth was the one that was the most powerful, and it showed me best on bare metal how a computer works.
progman 10y ago
> Variables have to go somewhere. As I already mentioned, in Forth you barely need variables. Everything happens on the stack. The rest is global. Forth requires a radical shift in thinking about programming. You should read Leo Brodie's book "Thinking Forth". http://thinking-forth.sourceforge.net/ http://thinking-forth.sourceforge.net/ > Good luck finding them amidst all the confusing rolling, picking, duping, etc. Good Forth code style uses comments all the time. For instance: ( swap the two top values ) : myswap ( x y -- y x) <= x y is input, y x is output swap ( y x ) ; If you keep every Forth routine small then you can really have fun in Forth without local variables. By the way, I would never use Forth for big software. Forth is particularly powerful in tiny systems where every byte matters.

by dewster 10y ago

astrobe_ 10y ago

> Variables have to go somewhere. Good luck finding them amidst all the confusing rolling, picking, duping, etc. Of course you don't want to use roll or pick. That's tutorial-level knowledge that you shouldn't use them. What you do when you see that coming is that you offload something to a global variable. The "something" is often the central topic of some part of the program, like a file handle for instance. So it makes sense to put it in a variable because it's needed in many places.

progman 10y ago
> Of course you don't want to use roll or pick. That's tutorial-level knowledge that you shouldn't use them. I think the opposite is true. Basic, Assembler and Forth were my first languages. Forth was the one that was the most powerful, and it showed me best on bare metal how a computer works.

progman 10y ago

> Variables have to go somewhere. As I already mentioned, in Forth you barely need variables. Everything happens on the stack. The rest is global. Forth requires a radical shift in thinking about programming. You should read Leo Brodie's book "Thinking Forth". http://thinking-forth.sourceforge.net/ http://thinking-forth.sourceforge.net/ > Good luck finding them amidst all the confusing rolling, picking, duping, etc. Good Forth code style uses comments all the time. For instance: ( swap the two top values ) : myswap ( x y -- y x) <= x y is input, y x is output swap ( y x ) ; If you keep every Forth routine small then you can really have fun in Forth without local variables. By the way, I would never use Forth for big software. Forth is particularly powerful in tiny systems where every byte matters.