From: no.email@nospam.invalid   
      
   Hans Bezemer  writes:   
   > What bothers me most technologically is that parameters flow through   
   > the stack undisturbed. You break that paradigm when using locals. With   
   > locals you *HAVE TO* create some kind of stack frame that you have to   
   > destroy when you exit.   
      
   Forth programs very frequently end up juggling parameters and other data   
   to and from the return stack, instead of using locals.  Simple   
   implementations of locals put them in the return stack too.   
   "Destroying" the stack frame just means adjusting RP when the function   
   exits.  Usually a single instruction.   
      
   > Needless to say this copying, releasing and stuff takes time.   
      
   Similar to DUP (copy) or DROP (release).   
      
   > In all honesty I must state that this overhead is not always   
   > translated to a diminished performance   
      
   Right, I don't think one can assert a performance hit without   
   measurements supporting the idea.   
      
   > TL;DR my objections are mostly based on pure architectural arguments,   
   > rather than practicality.   
      
   Sure, that's reasonable, it's a matter of what you prefer.  That's   
   harder to take issue with than claims about performance.   
      
   > I also don't like Python, PHP and Perl for those very same reasons -   
      
   Those are at a totally different level than Forth, in terms of layers of   
   implementation and runtime libraries, overhead, etc.  It's better to   
   compare to something like C, or a hypothetical cleaned up version of C,   
   or even to Forth with locals ;).   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)