Why are :NONAME and [: different?

[none) (albert]

Before long I have used { and } for
:NONAME ... ;
and for
: .... [: ... ;] ;
alike.

The only addition was
: { ... STATE @ .. ;
: } ... STATE ! .. ;

The sequence { .. } leaves a literal, that should not be different
from interpret or compile state, compare the notation 'A' that is
valid through interpret and compile state and leave the same literal.

Do Forth's really run into difficulties with implementing this?
Or is it only possible on rigorously simple Forth's?

Notation matters. Leibniz over Newton.

Lambda's deserves a much more compact and elegant
notation than the clunky :NONAME !

Groetjes Albert

[Krishna Myneni]

Post by none) (albert
Before long I have used { and } for
:NONAME ... ;
and for
: .... [: ... ;] ;
alike.
The only addition was
: } ... STATE ! .. ;
The sequence { .. } leaves a literal, that should not be different
from interpret or compile state, compare the notation 'A' that is
valid through interpret and compile state and leave the same literal.
Do Forth's really run into difficulties with implementing this?
Or is it only possible on rigorously simple Forth's?
Notation matters. Leibniz over Newton.
Lambda's deserves a much more compact and elegant
notation than the clunky :NONAME !
Groetjes Albert

kForth's definitions of [: and ;]

: [: postpone [ :noname ; immediate

: ;] postpone ; ] postpone literal ; immediate


There's a statement somewhere in the standard (Forth-94/Forth-2012)
stating that standard code will not nest definitions, named or unnamed
-- probably as a concession to simple Forth systems.

--
Krishna

[none) (albert]

Post by Krishna Myneni

Post by none) (albert
Before long I have used { and } for
:NONAME ... ;
and for
: .... [: ... ;] ;
alike.
The only addition was
: } ... STATE ! .. ;
The sequence { .. } leaves a literal, that should not be different
from interpret or compile state, compare the notation 'A' that is
valid through interpret and compile state and leave the same literal.
Do Forth's really run into difficulties with implementing this?
Or is it only possible on rigorously simple Forth's?
Notation matters. Leibniz over Newton.
Lambda's deserves a much more compact and elegant
notation than the clunky :NONAME !
Groetjes Albert

kForth's definitions of [: and ;]
: [: postpone [ :noname ; immediate
: ;] postpone ; ] postpone literal ; immediate
There's a statement somewhere in the standard (Forth-94/Forth-2012)
stating that standard code will not nest definitions, named or unnamed
-- probably as a concession to simple Forth systems.

As long as we want to support [: , actually we support nested definitions.

Maybe that statement is becoming stale, as modern systems -- gforth iforth
kforth swiftforth mpeforth -- exhibit less and less restrictions.
As regards a simple Forth like ciforth, there is no problem either.
It is more like a simplification.

Post by Krishna Myneni
Krishna

Groetjes Albert

[Marcel Hendrix]

Post by none) (albert
Before long I have used { and } for
:NONAME ... ;
and for
: .... [: ... ;] ;
alike.
The only addition was
: } ... STATE ! .. ;
The sequence { .. } leaves a literal, that should not be different
from interpret or compile state, compare the notation 'A' that is
valid through interpret and compile state and leave the same literal.

You could have been more explicit when stating that this is simple in
traditional Forth, and some examples why you think different Forths
might have problems would have helped understanding the issues.

In e.g. iForth :NONAME is not really different from : , that is, locals
and recursion are supported, and there is compiler security.
For instance, locals require that the locals wordlist is first in the
search-order. Therefore ";" and some other words have to undo that
effect. A straightforward :NONAME will therefore make the locals
of the surrounding word invisible, while the point of the embedded
definition may be to export same. Also, RECURSE and MYSELF after
the :NONAME .. ; might find the wrong xt, and compiler security
may check that colon definitions are not accidentally nested and
that the compiler stack balances.
At least a subroutine-threaded compiler for sure will lay down
code for the :NONAME , and that code will be right in the middle
of the enclosing word if nothing special (markers?) is done.

Maybe there is no problem when the Forth considers data inside a
colon definition as pure data and maintains that data as lists, but
these fine points of Forth are by now 40 years old and forgotten
(by me).

-marcel

[dxforth]

Post by Marcel Hendrix

Post by none) (albert
Before long I have used { and } for
:NONAME ... ;
and for
: .... [: ... ;] ;
alike.
The only addition was
: } ... STATE ! .. ;
The sequence { .. } leaves a literal, that should not be different
from interpret or compile state, compare the notation 'A' that is
valid through interpret and compile state and leave the same literal.

You could have been more explicit when stating that this is simple in
traditional Forth, and some examples why you think different Forths
might have problems would have helped understanding the issues.
In e.g. iForth :NONAME is not really different from : , that is, locals
and recursion are supported, and there is compiler security.

Fig-Forth has compiler security in the form of CSP so even there state
needs to be saved/restored across quotations. Then there's the branching
hack to give the illusion of 'nested'. I like Elizabeth's response to
the whole thing at the time:

"Aside from looking obscure and clever and satisfying the "[x] can do
it, why not Forth?" test, what on earth does this buy you?"

Perhaps not surprisingly this was omitted from the 'official' discussion
and comments:

http://www.forth200x.org/quotations.txt

[NN]

Post by dxforth

Post by Marcel Hendrix

Post by none) (albert
Before long I have used { and } for
:NONAME ... ;
and for
: .... [: ... ;] ;
alike.
The only addition was
: } ... STATE ! .. ;
The sequence { .. } leaves a literal, that should not be different
from interpret or compile state, compare the notation 'A' that is
valid through interpret and compile state and leave the same literal.

You could have been more explicit when stating that this is simple in
traditional Forth, and some examples why you think different Forths
might have problems would have helped understanding the issues.
In e.g. iForth :NONAME is not really different from : , that is, locals
and recursion are supported, and there is compiler security.

Fig-Forth has compiler security in the form of CSP so even there state
needs to be saved/restored across quotations. Then there's the branching
hack to give the illusion of 'nested'. I like Elizabeth's response to
"Aside from looking obscure and clever and satisfying the "[x] can do
it, why not Forth?" test, what on earth does this buy you?"
Perhaps not surprisingly this was omitted from the 'official' discussion
http://www.forth200x.org/quotations.txt

The answer to Elizabeth's question is :

You might have come across the idea of "name code not data" or
name code not values ( https://concatenative.org/wiki/view/Concatenative%20language/Name%20code%20not%20values )

If thats is explored further to become dont name code and dont name values
then those unnamed code becomes quotations which exist only for as long as
needed.

What does it buy you ?
Your dictionary ceases to have "extra" words created to help other
words, reducing clutter and memory when its done too.

[none) (albert]

Post by NN

Post by dxforth

Post by Marcel Hendrix

Post by none) (albert
Before long I have used { and } for
:NONAME ... ;
and for
: .... [: ... ;] ;
alike.
The only addition was
: } ... STATE ! .. ;
The sequence { .. } leaves a literal, that should not be different
from interpret or compile state, compare the notation 'A' that is
valid through interpret and compile state and leave the same literal.

You could have been more explicit when stating that this is simple in
traditional Forth, and some examples why you think different Forths
might have problems would have helped understanding the issues.
In e.g. iForth :NONAME is not really different from : , that is, locals
and recursion are supported, and there is compiler security.

Fig-Forth has compiler security in the form of CSP so even there state
needs to be saved/restored across quotations. Then there's the branching
hack to give the illusion of 'nested'. I like Elizabeth's response to
"Aside from looking obscure and clever and satisfying the "[x] can do
it, why not Forth?" test, what on earth does this buy you?"
Perhaps not surprisingly this was omitted from the 'official' discussion
http://www.forth200x.org/quotations.txt

You might have come across the idea of "name code not data" or
name code not values ( https://concatenative.org/wiki/view/Concatenative%20language/Name%20code%20not%20values )
If thats is explored further to become dont name code and dont name values
then those unnamed code becomes quotations which exist only for as long as
needed.
What does it buy you ?
Your dictionary ceases to have "extra" words created to help other
words, reducing clutter and memory when its done too.

For example
"
: (ABORT") ROT IF ETYPE ABORT ELSE 2DROP THEN ;

: ABORT" ?COMP POSTPONE " '(ABORT") , ; IMMEDIATE

"
translates into
"
: ABORT" ?COMP POSTPONE "
{ ROT IF ETYPE ABORT ELSE 2DROP THEN } ,
; IMMEDIATE
"

(ABORT") is no longer present in the headers, no need to document, and
actually ABORT" becomes easier to understand.
(Maybe " --> s" , --> compile, ' --> ['] )
The dependant word (ABORT") is almost impossible to
document properly. Then the only conclusion the reader gets that
there is no need to understand the word in the first place.

Groetjes Albert

[dxforth]

Post by NN

Post by dxforth

Post by Marcel Hendrix

Post by none) (albert
Before long I have used { and } for
:NONAME ... ;
and for
: .... [: ... ;] ;
alike.
The only addition was
: } ... STATE ! .. ;
The sequence { .. } leaves a literal, that should not be different
from interpret or compile state, compare the notation 'A' that is
valid through interpret and compile state and leave the same literal.

You could have been more explicit when stating that this is simple in
traditional Forth, and some examples why you think different Forths
might have problems would have helped understanding the issues.
In e.g. iForth :NONAME is not really different from : , that is, locals
and recursion are supported, and there is compiler security.

Fig-Forth has compiler security in the form of CSP so even there state
needs to be saved/restored across quotations. Then there's the branching
hack to give the illusion of 'nested'. I like Elizabeth's response to
"Aside from looking obscure and clever and satisfying the "[x] can do
it, why not Forth?" test, what on earth does this buy you?"
Perhaps not surprisingly this was omitted from the 'official' discussion
http://www.forth200x.org/quotations.txt

You might have come across the idea of "name code not data" or
name code not values ( https://concatenative.org/wiki/view/Concatenative%20language/Name%20code%20not%20values )
If thats is explored further to become dont name code and dont name values
then those unnamed code becomes quotations which exist only for as long as
needed.
What does it buy you ?
Your dictionary ceases to have "extra" words created to help other
words, reducing clutter and memory when its done too.

Naming a function describes what it does and adds legibility. It's why Moore
favours short routines - it's about names, not code. Quotations don't reduce
clutter; they create it by putting code where it has no right to be. At this
point some will defend quotations by showing them used in defining words that
use multiple xt's. Well, if that's all they're good for, then I don't have
that problem.

[Anton Ertl]

Post by NN
What does it buy you ?
Your dictionary ceases to have "extra" words created to help other
words, reducing clutter and memory when its done too.

Another advantage is that you don't have to look up the code
elsewhere. Compare the following definitions of +FIELD, one with an
unnamed definition, and one with a named definition:

Unnamed:

: +field1 ( n1 n2 "name" -- n3 )
create over , +
does>
@ + ;

Equivalently, also unnamed:

: +field2 ( n1 n2 "name" -- n3 )
create over , +
[: @ + ;] set-does> ;

Named:

: do+field ( addr1 a-addr2 -- addr3 )
@ + ;

: +field3 ( n1 n2 "name" -- n3 )
create over , +
['] do+field set-does> ;

However unnamed definitions also have a disadvantage: When using the
introspection features of a Forth system, unnamed definitions
don't tell the user much. E.g.:

1 1 +field1 f1
1 2 +field3 f3
`f1 .hm
\ output contains, among other things:
\ extra: $7F3E058EE1E0

`f3 .hm
\ output contains, among other things:
\ extra: do+field

- anton

[none) (albert]

Post by Marcel Hendrix

Post by none) (albert
Before long I have used { and } for
:NONAME ... ;
and for
: .... [: ... ;] ;
alike.
The only addition was
: } ... STATE ! .. ;
The sequence { .. } leaves a literal, that should not be different
from interpret or compile state, compare the notation 'A' that is
valid through interpret and compile state and leave the same literal.

You could have been more explicit when stating that this is simple in
traditional Forth, and some examples why you think different Forths
might have problems would have helped understanding the issues.

I could not possibly predict what problems more complicated
Forth's have.

Post by Marcel Hendrix
In e.g. iForth :NONAME is not really different from : , that is, locals
and recursion are supported, and there is compiler security.
For instance, locals require that the locals wordlist is first in the
search-order. Therefore ";" and some other words have to undo that
effect. A straightforward :NONAME will therefore make the locals
of the surrounding word invisible, while the point of the embedded
definition may be to export same. Also, RECURSE and MYSELF after
the :NONAME .. ; might find the wrong xt, and compiler security
may check that colon definitions are not accidentally nested and
that the compiler stack balances.

I have an other take on this.
"local value" 's are a design error, and leads to a cul-de-sac.
My experimental lucky7 has not merely local definitions that are
identical to outside definitions. (So if you have class rectangle
you can define a rectangle inside.)
Also a local execution word can have their own locals and their own
local execution words and so on recursively.
You give up on re-entrancy that is a dogma

Post by Marcel Hendrix
At least a subroutine-threaded compiler for sure will lay down
code for the :NONAME , and that code will be right in the middle
of the enclosing word if nothing special (markers?) is done.

I do nothing special and it is right in the middle of the enclosing
word. So what? In my philosophy, if you aim for extreme speed,
you use an optimiser.

Post by Marcel Hendrix
Maybe there is no problem when the Forth considers data inside a
colon definition as pure data and maintains that data as lists, but
these fine points of Forth are by now 40 years old and forgotten
(by me).

Lists are practical, but not for Forth with a million words.
The words that would be local to e.g. MERGE-SORT would be less
than a dozen, and a list is practical.

Post by Marcel Hendrix
-marcel

[Anton Ertl]

Post by none) (albert
Do Forth's really run into difficulties with implementing this?

Gforth has interpretation semantics for [:...;]. The overall code for
[:...;] is quite elaborate:

: (int-;]) ( some-sys lastxt -- ) >r hm, wrap! r> ;
: (;]) ( some-sys lastxt -- )

Post by none) (albert
r

] postpone ENDSCOPE third locals-list ! postpone ENDSCOPE
finish-code hm, previous-section wrap! dead-code off
r> postpone Literal ;

: int-[: ( -- flag colon-sys )
wrap@ ['] (int-;]) :noname ;
: comp-[: ( -- quotation-sys flag colon-sys )
wrap@ next-section finish-code|
postpone SCOPE locals-list off postpone SCOPE
['] (;]) :noname ;
' int-[: ' comp-[: interpret/compile: [: ( compile-time: -- quotation-sys flag colon-sys ) \ gforth bracket-colon
\G Starts a quotation

: ;] ( compile-time: quotation-sys -- ; run-time: -- xt ) \ gforth semi-bracket
\g ends a quotation
POSTPONE ; swap execute ( xt ) ; immediate

Even with the interpretation semantics for [:, there is a difference
from :NONAME: After [:...;] restores LATESTXT etc., while :NONAME does
not.

- anton

[none) (albert]

Post by Anton Ertl

Post by none) (albert
Do Forth's really run into difficulties with implementing this?

Gforth has interpretation semantics for [:...;]. The overall code for

So, it is doable. [: ... ;] looks pretty silly if you are in interpret
mode ...

Post by Anton Ertl
: (int-;]) ( some-sys lastxt -- ) >r hm, wrap! r> ;
: (;]) ( some-sys lastxt -- )

Post by none) (albert
r

] postpone ENDSCOPE third locals-list ! postpone ENDSCOPE
finish-code hm, previous-section wrap! dead-code off
r> postpone Literal ;
: int-[: ( -- flag colon-sys )
: comp-[: ( -- quotation-sys flag colon-sys )
postpone SCOPE locals-list off postpone SCOPE
['] (;]) :noname ;
' int-[: ' comp-[: interpret/compile: [: ( compile-time: --
quotation-sys flag colon-sys ) \ gforth bracket-colon
\G Starts a quotation
: ;] ( compile-time: quotation-sys -- ; run-time: -- xt ) \ gforth semi-bracket
\g ends a quotation
POSTPONE ; swap execute ( xt ) ; immediate
Even with the interpretation semantics for [:, there is a difference
from :NONAME: After [:...;] restores LATESTXT etc., while :NONAME does
not.

So it is doable. My definition for :NONAME was
: :NONAME ": NONAME" EVALUATE ;
The lambda notation { } generates an xt but not a dictionary entry,
so IMMEDIATE e.g. will not work, but doesn't make sense.
As long as the Forth standard refers to "most recently definitions" it
can't be helped, that such discrepancies occur.

Post by Anton Ertl
- anton

Groetjes Albert

[[e-mail]]

Post by none) (albert

Post by none) (albert
Do Forth's really run into difficulties with implementing this?

Gforth has interpretation semantics for [:...;]. The overall code for

So, it is doable. [: ... ;] looks pretty silly if you are in interpret
mode ...
10 [: 1e ;] [: -1e ;] 2dup swap [: 0e ;] A f.

for expressing Knuth's man-or-boy test in Forth.
(copied from Rosetta Code).