home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.forth      Forth programmers eat a lot of Bratwurst      117,927 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 117,381 of 117,927   
   minforth to All   
   Re: Nested definitions   
   02 Jul 25 18:15:56   
   
   From: minforth@gmx.net   
      
   Am 02.07.2025 um 11:50 schrieb Ruvim:   
   > On 2025-07-02 13:02, minforth wrote:   
   >> Am 02.07.2025 um 10:53 schrieb Ruvim:   
   >>> On 2025-06-24 01:03, minforth wrote:   
   >>> [...]   
   >>>   
   >>>> 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 ... > ;>   
   >>>   
   >>> BTW, why do you prefer the special syntax `<: ... ;>`   
   >>> over an extension to the existing words `:` and `;`   
   >>>   
   >>>    : SOME-APP   
   >>>       [ : FUNC < ... calc function ... > ; ]   
   >>>       < ... >   
   >>>    ;   
   >>>   
   >>> In this approach the word `:` knows that it's a nested definition and   
   >>> behaves accordingly.   
   >> Are you sure? gforth test:   
   >>   
   >> : APP 1 [ : func 2 ; ] func ;  ok   
   >> app   
   >> *the terminal*:2:1: error: Invalid memory address   
   >   
   > This is not standard, just like `<: ;>`   
   >   
   > My question is why did you introduce `<:` and `;>` instead of extending   
   > the `:` and `;` behavior?   
   >   
      
   It came naturally and cheaply once I had XT: type locals.   
   BTW, Gforth has them too.   
      
   When called, normal locals push their value onto the stack.   
   XT: locals also execute their pushed xt.   
      
   Then, with quotations, embedded functions can be emulated:   
      
      [: ... calc function ... ;] { xt: func } ...   
      
   Whenever you subsequently call "func" within the enclosing parent   
   word, the quotation is executed. The embedded function header is   
   temporary and it does not occupy dictionary space after the end   
   of the parent function.   
      
   For the sake of my tired eyes, I just added some syntactic sugar:   
      
       <: FUNC ... calc function ... ;> ...   
      
   which does the same thing behind the scenes.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca