Re: Nested definitions

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.