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

app<<<

Backtrace:
kernel/int.fs:594:10 0 $6FFFFF7FDE28 int-execute

MinForth 3.6 test:

# : APP 1 <: func 2 ;> func ; ok
# app ok
1 2 #

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ruvim <ruvim.pinka@gmail.com> writes:

On 2025-07-02 15:37, albert@spenarnc.xs4all.nl wrote:

Or it has not even know it, if [ is smart enough to compile a jump to
after ].

This can be tricky because the following should work:

create foo [ 123 , ] [ 456 ,

: bar [ ' foo compile, 123 lit, ] ;

Or something. Anyway, [ and ] are used for a variety of purposes and
trying to smarten them seems fraught with pitfalls. If one really
wants to have

: foo ... [ : bar ... ; ] ... ;

work, it may be better to put the smarts into : and ;. E.g., on a
system with sections, they could switch to another section and back.

The benefit of defining a normal colon definition inside another colon definition eludes me, however. Maybe mutual recursion, but the need
is rare and deferred words handle that well.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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: fsxNet Usenet Gateway (21:1/5)

Am 02.07.2025 um 17:12 schrieb Anton Ertl:

Ruvim <ruvim.pinka@gmail.com> writes:

On 2025-07-02 15:37, albert@spenarnc.xs4all.nl wrote:

Or it has not even know it, if [ is smart enough to compile a jump to
after ].

This can be tricky because the following should work:

create foo [ 123 , ] [ 456 ,

: bar [ ' foo compile, 123 lit, ] ;

The benefit of defining a normal colon definition inside another colon definition eludes me, however. Maybe mutual recursion, but the need
is rare and deferred words handle that well.

Many roads lead to Rome. By accident, my quotations have read/write
access to the locals of the parent function, but not vice versa.

Apart from function encapsulation, the benefit is that I don't
have to pass all quotation parameters over the stack, which makes
the code very straightforward and readable.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ruvim <ruvim.pinka@gmail.com> writes:

On 2025-07-02 19:12, Anton Ertl wrote:

The benefit of defining a normal colon definition inside another colon
definition eludes me, however. Maybe mutual recursion, but the need
is rare and deferred words handle that well.

As I can see, the idea is that the name of a nested definition has the >limited scope — the same as a local variable, and it is not visible
outside of the containing definition.

I have found the limited scope to be a hindrance, not a help: When I
want to debug, I want to call the word, but if it is not visible,
that's hard. There is a compromise: The scope recognizer allows to
invoke a word X in a vocabulary V with the syntax V:X:

vocabulary foo ok
also foo definitions ok
create foo1 ok
previous definitions ok
foo1
*the terminal*:9:1: error: Undefined word

foo1<<<

Backtrace:
kernel/recognizer.fs:89:21: 0 $7FCA47A12FF8 throw
foo:foo1 hex. \ output: $7FCA47AA0DE8 ok

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <1043831$3ggg9$1@dont-email.me>,
Ruvim <ruvim.pinka@gmail.com> wrote:

On 2025-07-02 15:37, albert@spenarnc.xs4all.nl wrote:

In article <1042s2o$3d58h$1@dont-email.me>,
Ruvim <ruvim.pinka@gmail.com> wrote:

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.

Or it has not even know it, if [ is smart enough to compile a jump to
after ].

This can be tricky because the following should work:

create foo [ 123 , ] [ 456 ,

: bar [ ' foo compile, 123 lit, ] ;

If this bothers you, rename it in [[ ]].

Once we enhance [ ] to do things prohibited by the standard,
(adding nested definitions) I can't be bothered with this too much.

--
Ruvim

Groetjes Albert
--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 3 Jul 2025 20:47:07 +0400
Ruvim <ruvim.pinka@gmail.com> wrote:

On 2025-07-03 17:11, albert@spenarnc.xs4all.nl wrote:

In article <1043831$3ggg9$1@dont-email.me>,
Ruvim <ruvim.pinka@gmail.com> wrote:

On 2025-07-02 15:37, albert@spenarnc.xs4all.nl wrote:

In article <1042s2o$3d58h$1@dont-email.me>,
Ruvim <ruvim.pinka@gmail.com> wrote:

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.

Or it has not even know it, if [ is smart enough to compile a
jump to after ].

This can be tricky because the following should work:

create foo [ 123 , ] [ 456 ,

: bar [ ' foo compile, 123 lit, ] ;

If this bothers you, rename it in [[ ]].

Once we enhance [ ] to do things prohibited by the standard,
(adding nested definitions) I can't be bothered with this too much.

The standard does not prohibit a system from supporting nested
definitions in whichever way that does not violate the standard
behavior.

Yes, something like "private[ ... ]private" is a possible approach,
and its implementation seems simpler than adding the smarts to `:`
and `;` (and other defining words, if any).

The advantage of this approach over "<: ... ;>" is that you can
define not only colon-definitions, but also constants, variables,
immediate words, one-time macros, etc.

: foo ( F: r.coefficient -- r.result )
private[
variable cnt
0e fvalue k
: [x] ... ; immediate
]private
to k 0 cnt !
...
;

It's also possible to associated the word list of private words with
the containing word xt for debugging purposes.

--
Ruvim

In lxf I have module, private, public, end-module
your example would be

module
private

variable cnt
0e fvalue k
: [x] ... ; immediate

public

: foo ( F: r.coefficient -- r.result )
to k 0 cnt !
...
;

end-module

end-module will remove all headers from the private words in the module
I am not found of mixing definitions inside others.

BR
Peter


--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 3 Jul 2025 17:42:02 +0000, peter wrote:

In lxf I have module, private, public, end-module
your example would be

module
private

variable cnt
0e fvalue k
: [x] ... ; immediate

public

: foo ( F: r.coefficient -- r.result )
to k 0 cnt !
...
;

end-module

end-module will remove all headers from the private words in the module
I am not fond of mixing definitions inside others.

Section 3.4.5 of the standard document is very clear on this.
On the other hand, quotations do not fall under this verdict
because neither namespace nor search order management is
required.

My <: func .. ;> emulation uses quotations. No big deal.
I find it useful every now and then.

--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <1046c6b$8gru$1@dont-email.me>,
Ruvim <ruvim.pinka@gmail.com> wrote:
<SNIP>

The standard does not prohibit a system from supporting nested
definitions in whichever way that does not violate the standard behavior.

You are right. Same mistake again.
<SNIP>

It's also possible to associated the word list of private words with the >containing word xt for debugging purposes.

Easier, after debugging just smudge (HIDE) those definitions.

If you use a a separate wordlist PRIME for a facility:

FROM PRIME IMPORT INIT-SIEVE PRIME?

(Whatever is in the wordlist PRIME , only keep ALIAS for INIT-SIEVE and
PRIME? in CURRENT.)

--
Ruvim

--
The Chinese government is satisfied with its military superiority over USA.
The next 5 year plan has as primary goal to advance life expectancy
over 80 years, like Western Europe.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)