From: peter.noreply@tin.it   
      
   On Tue, 01 Jul 2025 11:40:38 -0700   
   Paul Rubin  wrote:   
      
   > Hans Bezemer  writes:   
   > >>> But such would indicate a deficiency in Forth.  Do C programmers   
   > >>> reach a point at which they can't go forward? ...   
   > > Another great argument to leave Forth and embrace C! Why painfully   
   > > create kludge to cram into a language that was clearly not created   
   > > for that when you have a language available that was actually   
   > > DESIGNED with those requirements in mind?!   
   >   
   > I'm not sure what you're getting at here, though I see the sarcasm.   
   >   
   > Is the kludge locals?  They don't seem that kludgy to me.   
   > Implementing them in Forth is straightforward and lots of people have   
   > done it.   
   >   
   > The point where one can't go forward is basically "running out of   
   > registers".  In assembly language those are the machine registers, and   
   > in Forth they're the top few stack slots.  In both cases, when you run   
   > out, you have to resort to contorted code.   
   >   
   > In C that isn't a problem for the programmer.  You can use as many   
   > variables as you like, and if the compiler runs out of registers and   
   > has to make contorted assembly code, it does so without your having   
   > to care.   
   >   
   > In a traditional Forth with locals, the locals are stack allocated so   
   > accessing them usually costs a memory reference.  The programmer gets   
   > the same convenience as a C programmer.  The runtime takes a slowdown   
   > compared to code from a register-allocating compiler, but such a   
   > slowdown is already present in a threaded interpreter, so it's fine.   
   >   
   > Finally, a fancy enough Forth compiler can do the same things that a C   
   > compiler does.  Those compilers are difficult to write, but they exist   
   > (VFX, lxf, etc.).  I don't know if locals make writing the compiler   
   > more difficult.  But the user shouldn't have to care.   
      
   The code generator in lxf has no knowledge of what a local is.   
   locals are conceptually placed on the return stack. lxf is as smart   
   about the return stack as the data stack. that is why it can produce   
   very efficient code for simple examples like 3DUP. The actual   
   implementation of local in the interpreter is just a few lines of code.   
   The difference with locals will be seen when you have a boundary block,   
   IF statement, a call etc that require a known state of the stacks.   
   The real problem for me with locals is that their scope is to the end   
   of the definition. With the stack you end the scope of an item with a   
   drop and extend it with a dup, very elegant!   
   A multipass compiler can of course find the scope of each local but at   
   the cost of more complexity.   
      
   In lxf64 I have introduced a local stack with the same capabilities as   
   the data and return stack. I am not sure yet if this is better.   
      
   The nice thing is that I now have >ls ls> and ls@. Compared with the   
   return stack this also works across words. One word can put stuff on   
   the localstack and another retrieve it. This is sometimes very useful.   
      
   BR   
   Peter   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)