From: minforth@gmx.net   
      
   Am 01.07.2025 um 23:47 schrieb peter:   
   > 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.   
   >>   
   >> 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.   
      
   In a sense, such locals become global. I am not sure if this opens the   
   way inadvertently for hard-to-detect bugs. One rarely discussed property   
   of locals is that they offer data encapsulation (or have scope in C   
   terminology).   
      
   Only one useful application comes to my mind: sharing locals between   
   quotation and its parent function, i.e. for creating closures. But who   
   needs thema anyway?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)