From: the.beez.speaks@gmail.com   
      
   On 24-06-2025 07:31, dxf wrote:   
   > On 24/06/2025 10:42 am, minforth wrote:   
   >> On Mon, 23 Jun 2025 21:20:46 +0000, Hans Bezemer wrote:   
   >>   
   >>> On 23-06-2025 23:03, minforth wrote:   
   >>>> On Mon, 23 Jun 2025 5:18:34 +0000, Anton Ertl wrote:   
   >>>>   
   >>>>> minforth@gmx.net (minforth) writes:   
   >>>>>> So, I made me a small extension to the locals word set. Using your   
   >>>>>> example SPIN (abc — cba), I can define it as follows:   
   >>>>>> : SPIN { a b c == c b a } ; \ no need for additional code before ;   
   >>>>>   
   >>>>> What is the advantage of using this extension over the Forth-2012:   
   >>>>>   
   >>>>> : spin {: a b c :} c b a ;   
   >>>>>   
   >>>>> ?   
   >>>>   
   >>>> Obviously, there is no advantage for such small definitions.   
   >>>>   
   >>>> For me, the small syntax extension is a convenience when working   
   >>>> with longer definitions. A bit contrived (:= synonym for TO):   
   >>>>   
   >>>> : SOME-APP { a f: b c | temp == n: flag z: freq }   
   >>>> \ inputs: integer a, floats b c   
   >>>> \ uninitialized: float temp   
   >>>> \ outputs: integer flag, complex freq   
   >>>>    <: FUNC < ... calc function ... > ;>   
   >>>> \ emulated embedded function using { | xt: func }   
   >>>>    < ... calc something ... > := temp   
   >>>>    < ... calc other things ... > := freq  / basic formula   
   >>>>    < ... calc other things ... > := flag   
   >>>>    < ... calc correction ... > := freq  / better estimation   
   >>>> ;   
   >>>>   
   >>>> While working on such things, I can focus my eyes on the formulas,   
   >>>> all local values are visible in one place, and I don't have to   
   >>>> worry about tracking the data stack(s) for lost/accumulated items.   
   >>>>   
   >>>> As I said, it is nothing spectacular, just helpful. And to my own   
   >>>> eyes, it looks neater.  ;-)   
   >>>>   
   >>>> And before dxf yowls again: it is still Forth. :o)   
   >>>   
   >>> Well.. Technically everything written in Forth is Forth. But it is not   
   >>> canonical Forth - because if it were canonical Forth, we would have   
   >>> covered locals in "Starting Forth" - and we didn't.   
   >>>   
   >>> Now, let's assume we found we were wrong. But there was a chapter in   
   >>> "Thinking Forth" called "The stylish stack" - not "The stylish locals".   
   >>> As a matter of fact, it states that "the stack is not an array" -   
   >>> meaning: not randomly accessible. And what are locals? Right. Randomly   
   >>> accessible.   
   >>>   
   >>> So, what is this? It's a feeble imitation of C. It's not part of the   
   >>> original design. Because if it were part of the original design, you   
   >>> would find out what it means to think differently. This is merely C   
   >>> thinking. Nothing else. Certainly not Forth thinking.   
   >>>   
   >>   
   >> LOL ... I admit being a very non-canonical old guy :O)   
   >   
   > 'Look, Ma - I've solved Forth's biggest problem.' ;-)   
      
   No really, I'm not kidding. When done properly Forth actually changes   
   the way you work. Fundamentally. I explained the sensation at the end of   
   "Why Choose Forth". I've been able to tackle things I would never have   
   been to tackle with a C mindset. ( https://youtu.be/MXKZPGzlx14 )   
      
   Like I always wanted to do a real programming language - no matter how   
   primitive. Now I've done at least a dozen - and that particular trick   
   seems to get easier by the day.   
      
   And IMHO a lot can be traced back to the very simple principles Forth is   
   based upon - like a stack. Or the triad "Execute-Number-Error". Or the   
   dictionary. But also the lessons from ThinkForth.   
      
   You'll also find it in my C work. There are a lot more "small functions"   
   than in your average C program. It works for me like an "inner API". Not   
   to mention uBasic/4tH - There are plenty of "one-liners" in my   
   uBasic/4tH programs.   
      
   But that train of thought needs to be maintained - and it can only be   
   maintained by submitting to the very philosophy Forth was built upon. I   
   feel like if I would give in to locals, I'd be back to being an average   
   C programmer.   
      
   I still do C from time to time - but it's not my prime language. For   
   this reason - and because I'm often just plain faster when using Forth.   
   It just results in a better program.   
      
   The only thing I can say is, "it works for me". And when I sometimes   
   view the works of others - especially when resorting to a C style - I   
   feel like it could work for you as well.   
      
   Nine times out of ten one doesn't need the amount of locals which are   
   applied. One doesn't need a 16 line word - at least not when you   
   actually want to maintain the darn thing. One could tackle the problem   
   much more elegant.   
      
   It's that feeling..   
      
   Hans Bezemer   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)