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
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

[Krishna Myneni]

On 1/22/23 07:39, albert wrote:
> 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

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]

In article <tqjjeo$353q3$2...@dont-email.me>,

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.

>Krishna

[Marcel Hendrix]

On Sunday, January 22, 2023 at 2:39:25 PM UTC+1, none albert wrote:
> 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.

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

[Anton Ertl]

albert@cherry.(none) (albert) writes:
>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 -- )
>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
--
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 2022: https://euro.theforth.net

[dxforth]

On 23/01/2023 4:41 am, Marcel Hendrix wrote:
> On Sunday, January 22, 2023 at 2:39:25 PM UTC+1, none albert wrote:
>> 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.
>
> 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

[none albert]

In article <5797d264-cb1d-4d07...@googlegroups.com>,

Marcel Hendrix <m...@iae.nl> wrote:
>On Sunday, January 22, 2023 at 2:39:25 PM UTC+1, none albert wrote:
>> 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.
>
>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.

>
>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

>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.

>
>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.
>
>-marcel

[none albert]

In article <2023Jan2...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>albert@cherry.(none) (albert) writes:
>>Do Forth's really run into difficulties with implementing this?
>
>Gforth has interpretation semantics for [:...;]. The overall code for
>[:...;] is quite elaborate:

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

>
>: (int-;]) ( some-sys lastxt -- ) >r hm, wrap! r> ;
>: (;]) ( some-sys lastxt -- )
> >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.

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.

>
>- anton

[minf...@arcor.de]

none albert schrieb am Montag, 23. Januar 2023 um 11:56:41 UTC+1:
> In article <2023Jan2...@mips.complang.tuwien.ac.at>,
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >albert@cherry.(none) (albert) writes:
> >>Do Forth's really run into difficulties with implementing this?
> >
> >Gforth has interpretation semantics for [:...;]. The overall code for
> >[:...;] is quite elaborate:
> So, it is doable. [: ... ;] looks pretty silly if you are in interpret
> mode ...

YMMV but I found this is looking quite concise:
> 10 [: 1e ;] [: -1e ;] 2dup swap [: 0e ;] A f.
for expressing Knuth's man-or-boy test in Forth.
(copied from Rosetta Code).

[NN]

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]

In article <11298bc1-490f-46e8...@googlegroups.com>,

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.

[dxforth]

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]

NN <novembe...@gmail.com> writes:
>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