clarification on CREATE and colon :

[Krishna Myneni]

Two points of clarification are needed.

1) For CREATE does the 2012 standard permit the possibility of a
standardized word [MY-NAME] used in the following way:

: person CREATE [MY-NAME] , DOES> ." My name is " NAME>STRING TYPE ;

where [MY-NAME] has the compilation semantics of compiling the created
word's "nt" into the definition. Then, the use would be

person ALICE
person BHASKAR

Executing ALICE (or BHASKAR) would display

My name is ALICE (or BHASKAR)

2) The following will not compile in Gforth 0.7.9:

' emit
: test 65 [ compile, ] ;

The above works in kForth: executing TEST emits an 'A'. It appears that
the ":" operator is pushing stuff onto the stack in Gforth, as seen by

' emit
: test [ .s ] ;

I thought the control stack (C:) was to be used for compilation related
items. Is it clearly stated in the standard that the data stack may be
used by ":"?

Krishna Myneni

[hughag...@gmail.com]

On Thursday, August 29, 2019 at 9:36:51 PM UTC-7, Krishna Myneni wrote:
> 2) The following will not compile in Gforth 0.7.9:
>
> ' emit
> : test 65 [ compile, ] ;
>
> The above works in kForth: executing TEST emits an 'A'. It appears that
> the ":" operator is pushing stuff onto the stack in Gforth, as seen by
>
> ' emit
> : test [ .s ] ;
>
> I thought the control stack (C:) was to be used for compilation related
> items. Is it clearly stated in the standard that the data stack may be
> used by ":"?

The documentation for : (6.1.0450) does not indicate that the control-flow
stack is used. Nowhere does the ANS-Forth document say that : may
put data on the control-flow stack --- nowhere does it say that : does NOT
put data on the control-flow stack though, so it is legal for it to do so.

As a practical matter, all of the compiling words such as IF etc.
do use the control-flow stack (and their documentation says that they do),
so you can generally assume that the control-flow stack is in use.

The control-flow stack corrupts the data-stack.
See section 3.2.3.2:
---------------------------------------------------------------------
The control-flow stack may, but need not, physically exist
in an implementation. If it does exist, it maybe, but need not be,
implemented using the data stack. The format of the control-flow stack
is implementation defined. Since the control-flow stack may be implemented
using the data stack, items placed on the data stack are unavailable
to a program after items are placed on the control-flow stack
and remain unavailable until the control-flow stack items are removed.
---------------------------------------------------------------------

[Anton Ertl]

Krishna Myneni <krishna...@ccreweb.org> writes:
>Two points of clarification are needed.
>
>1) For CREATE does the 2012 standard permit the possibility of a
>standardized word [MY-NAME] used in the following way:
>
>: person CREATE [MY-NAME] , DOES> ." My name is " NAME>STRING TYPE ;
>
>where [MY-NAME] has the compilation semantics of compiling the created
>word's "nt" into the definition.

The word [MY-NAME] is not standardized. LATEST ( -- nt ) is also not
standardized.

But you can define PERSON as follows:

: person
>in @ create >in ! parse-name get-current find-name-in ,
does> ( -- )
@ ." My name is " name>string type ;

FIND-NAME-IN is defined in Forth-2012 in the reference implementation
of FIND-NAME-IN:
<http://www.forth200x.org/reference-implementations/find-name.fs>

>2) The following will not compile in Gforth 0.7.9:
>
>' emit
>: test 65 [ compile, ] ;
>
>The above works in kForth: executing TEST emits an 'A'. It appears that
>the ":" operator is pushing stuff onto the stack in Gforth, as seen by
>
>' emit
>: test [ .s ] ;
>
>I thought the control stack (C:) was to be used for compilation related
>items. Is it clearly stated in the standard that the data stack may be
>used by ":"?

|3.1.5.1 System-compilation types
|
|These data types denote zero or more items on the control-flow stack
|(see 3.2.3.2). [...]
|
|The implementation-dependent data generated upon beginning to compile
|a definition and consumed at its close is represented by the symbol
|colon-sys throughout this standard.
|
|3.2.3.2 Control-flow stack

|
|The control-flow stack may, but need not, physically exist in an

|implementation. If it does exist, it may be, but need not be,

|implemented using the data stack.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2019: http://euro.theforth.net/

[Krishna Myneni]

On Fri, 30 Aug 2019 06:58:03 +0000, Anton Ertl wrote:

> Krishna Myneni <krishna...@ccreweb.org> writes:
>>Two points of clarification are needed.
>>
>>1) For CREATE does the 2012 standard permit the possibility of a
>>standardized word [MY-NAME] used in the following way:
>>
>>: person CREATE [MY-NAME] , DOES> ." My name is " NAME>STRING TYPE ;
>>
>>where [MY-NAME] has the compilation semantics of compiling the created
>>word's "nt" into the definition.
>
> The word [MY-NAME] is not standardized. LATEST ( -- nt ) is also not
> standardized.
>

Is there a proposal to standardize LATEST ?

> But you can define PERSON as follows:
>
> : person
> >in @ create >in ! parse-name get-current find-name-in ,
> does> ( -- )
> @ ." My name is " name>string type ;
>

I realize that the input stream can be manipulated in standard Forth to
accomplish the function. But, my question was probably not explicit
enough. Can the "nt" be obtained, within the framework of the standard,
after ":" or CREATE but not necessarily before the name becomes
searchable in the dictionary? Thus, the use of >IN PARSE-NAME and FIND-
NAME-IN will likely not work for the following example, without
redefining ":"

: computer [MY-NAME] CREATE , [MY-NAME] , DOES>
DUP CELL+ @ NAME>STRING ." My name is " TYPE cr
@ NAME>STRING ." I am a " TYPE cr
;

computer HAL
HAL

displays

My name is HAL
I am a COMPUTER

> FIND-NAME-IN is defined in Forth-2012 in the reference implementation of
> FIND-NAME-IN:
> <http://www.forth200x.org/reference-implementations/find-name.fs>
>

Don't we have SEARCH-WORDLIST for this?

>>2) The following will not compile in Gforth 0.7.9:
>>
>>' emit : test 65 [ compile, ] ;
>>

...

>>items. Is it clearly stated in the standard that the data stack may be
>>used by ":"?

> ...

> |3.2.3.2 Control-flow stack |
> |The control-flow stack may, but need not, physically exist in an
> |implementation. If it does exist, it may be, but need not be,
> |implemented using the data stack.
>

Thanks. I searched the pdf for the phrase "control stack" instead of
"control-flow stack".

Krishna

[none albert]

In article <3f9772ce-0117-4ae2...@googlegroups.com>,

That is all very sensible and to the point.
Looking forward to seeing more posts from you like this!

Groetjes Albert
--
This is the first day of the end of your life.
It may not kill you, but it does make your weaker.
If you can't beat them, too bad.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[none albert]

In article <2019Aug3...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>Krishna Myneni <krishna...@ccreweb.org> writes:
>>Two points of clarification are needed.
>>
>>1) For CREATE does the 2012 standard permit the possibility of a
>>standardized word [MY-NAME] used in the following way:
>>
>>: person CREATE [MY-NAME] , DOES> ." My name is " NAME>STRING TYPE ;
>>
>>where [MY-NAME] has the compilation semantics of compiling the created
>>word's "nt" into the definition.
>
>The word [MY-NAME] is not standardized. LATEST ( -- nt ) is also not
>standardized.
>
>But you can define PERSON as follows:
>
>: person
> >in @ create >in ! parse-name get-current find-name-in ,
>does> ( -- )
> @ ." My name is " name>string type ;

The double parsing trick is ugly and cumbersome.
It is time to get rid of it by e.g. standardising [MY-NAME] or LATEST.
I personally hate the use of the global >IN , the more so because
I have banned it from my implementation.

Or ...
Now that name token (dea) is official, it is time to have a CREATE that
leaves the name token.
CREATE-NT ( .. -- nt )
Perform all actions of create, and leave the name token of the
created word.

[I am already in the process of defining a factor
XXX such that the new definition of CREATE becomes : CREATE XXX DROP ;
CREATE ... DOES> ...
will then internally be replaced by
CREATE-DEA ... DEA-DOES>
where DEA-DOES> is like DOES> but expects a name token on the stack.
That also does away with the restriction on filling in the DOES>-field
only for LATEST, which is kind of bizar.
]

The example of Krishna then becomes:
: person CREATE-NT , DOES> ." My name is " NAME>STRING TYPE ;

>- anton

[hughag...@gmail.com]

You think I want praise from you? You're an arrogant little troll.

This is one of your typical attacks, less than 20 minutes previous.

On Friday, August 30, 2019 at 5:53:10 AM UTC-7, none albert wrote:
> In article <qk91p5$qja$1...@dont-email.me>,
> Alex McDonald <al...@rivadpm.com> wrote:
> >On 29-Aug-19 10:55, albert wrote:
> >> "xxx" WANTED ( sc -- )
> >>
> >> Check if xxx is available. If not, then load it by any means
> >> available. If it can not, report a warning.
> >>
> >> The shortness of the description, and the fact that I write down
> >> an unambiguous description out of my head, instead of a need to
> >> quote it, should convince everybody that this word is canonical
> >
> >Canonical doesn't quite mean "easily remembered".
>
> Huh? I used the word canonical to annoy Hugh. If it confuses
> other people, I'm sorry.
>
> >How do you find the wanted word so you can "load it by any means
> >available"? Is there an external list you maintain, or some kind of
> >key/value database?
>
> You shouldnt be concerned about that as you maintain nothing. As much
> as you are not concerned about where the hell gcc finds the address of
> malloc. That is the user's view.
>
> Now the implementors view. As an implementor I'm in the very best
> position to get this right...

[hughag...@gmail.com]

On Friday, August 30, 2019 at 12:43:25 AM UTC-7, Anton Ertl wrote:
> Krishna Myneni <krishna...@ccreweb.org> writes:

> >2) The following will not compile in Gforth 0.7.9:
> >
> >' emit
> >: test 65 [ compile, ] ;
> >
> >The above works in kForth: executing TEST emits an 'A'. It appears that
> >the ":" operator is pushing stuff onto the stack in Gforth, as seen by
> >
> >' emit
> >: test [ .s ] ;
> >
> >I thought the control stack (C:) was to be used for compilation related
> >items. Is it clearly stated in the standard that the data stack may be
> >used by ":"?
>
> |3.1.5.1 System-compilation types
> |
> |These data types denote zero or more items on the control-flow stack
> |(see 3.2.3.2). [...]
> |
> |The implementation-dependent data generated upon beginning to compile
> |a definition and consumed at its close is represented by the symbol
> |colon-sys throughout this standard.

The definition of : (6.1.0450) doesn't actually make any sense.
It says: ( C: “<spaces>name” -- colon-sys )
This indicates that the name string is on the control-flow stack.

> |3.2.3.2 Control-flow stack
> |
> |The control-flow stack may, but need not, physically exist in an
> |implementation. If it does exist, it may be, but need not be,
> |implemented using the data stack.

Are you willing to admit that section 3.2.3.2 indicates that
Elizabeth Rather is a blithering idiot?
If not, then STFU --- your opinion is worth as much as Albert's,
which is nothing --- you are Elizabeth Rather's brown-noser.

[Krishna Myneni]

On Fri, 30 Aug 2019 10:54:18 +0000, Krishna Myneni wrote:

> On Fri, 30 Aug 2019 06:58:03 +0000, Anton Ertl wrote:
>
>> Krishna Myneni <krishna...@ccreweb.org> writes:
>>>Two points of clarification are needed.
>>>
>>>1) For CREATE does the 2012 standard permit the possibility of a
>>>standardized word [MY-NAME] used in the following way:
>>>
>>>: person CREATE [MY-NAME] , DOES> ." My name is " NAME>STRING TYPE ;
>>>
>>>where [MY-NAME] has the compilation semantics of compiling the created
>>>word's "nt" into the definition.
>>

....

> : computer [MY-NAME] CREATE , [MY-NAME] , DOES>
> DUP CELL+ @ NAME>STRING ." My name is " TYPE cr @ NAME>STRING ." I
> am a " TYPE cr
> ;
>
> computer HAL HAL
>
> displays
>
> My name is HAL I am a COMPUTER
>

Ok, my example is wrong. The above example requires the non-immediate
word MY-NAME and it is used as follows -- this is an actual running
example:

----
\ kForth has no comma operator so I have to use ?allot
: computer
[ MY-NAME ] LITERAL CREATE
2 CELLS ?allot MY-NAME SWAP 2!
DOES>
DUP a@ ." My name is " NAME>STRING TYPE CR
CELL+ a@ ." I am a " NAME>STRING TYPE CR ;
ok
computer hal
ok
hal

My name is HAL
I am a COMPUTER

ok
----

The equivalent Forth-2102 code, assuming the existence of MY-NAME is:

----
: computer
[ MY-NAME ] LITERAL CREATE , MY-NAME ,
DOES>
DUP CELL+ @ ." My name is " NAME>STRING TYPE CR
@ ." I am a " NAME>STRING TYPE CR ;
----

KM

[dxforth]

On Friday, 30 August 2019 14:36:51 UTC+10, Krishna Myneni wrote:
> ...

> 2) The following will not compile in Gforth 0.7.9:
>
> ' emit
> : test 65 [ compile, ] ;
>
> The above works in kForth: executing TEST emits an 'A'. It appears that
> the ":" operator is pushing stuff onto the stack in Gforth, as seen by

The reason this fails on most forth is compiler security - which existed
since Fig-Forth. Typically : would read the current stack depth and ;
checked whether it had changed. This is covered by 'colon-sys' per
Anton's quote. Some systems (Swiftforth, DX-Forth) permit compiler
security to be temporarily disabled however it's then up to the user to
know how the system works internally and manage all potential conflicts.

\ DX-Forth

checking off

' emit
: test 65 [ compile, ] ;

checking on

test A ok

[dxforth]

On Saturday, 31 August 2019 01:00:06 UTC+10, hughag...@gmail.com wrote:
> ...

> You think I want praise from you? You're an arrogant little troll.

At the very least he should have known you can't be hand-fed. It's
the same miscalculation one forth standard after another has made.

[Anton Ertl]

Krishna Myneni <krishna...@ccreweb.org> writes:
>Is there a proposal to standardize LATEST ?

Not yet. Do you want to write it?

>Can the "nt" be obtained, within the framework of the standard,
>after ":" or CREATE but not necessarily before the name becomes
>searchable in the dictionary?

No.

>> FIND-NAME-IN is defined in Forth-2012 in the reference implementation of
>> FIND-NAME-IN:
>> <http://www.forth200x.org/reference-implementations/find-name.fs>
>>
>
>Don't we have SEARCH-WORDLIST for this?

SEARCH-WORDLIST produces an xt and a number, and suffers from most of
the problems of FIND.

[Krishna Myneni]

On Sun, 01 Sep 2019 16:27:40 +0000, Anton Ertl wrote:

> Krishna Myneni <krishna...@ccreweb.org> writes:
>>Is there a proposal to standardize LATEST ?
>
> Not yet. Do you want to write it?

Sure. I want to make sure I understand the correspondence between what I
implemeted as MY-NAME and LATEST . I believe they are, for the most part,
equivalent. I like "MY-NAME" since it is clear (to me) what it means when
it is used inside of a colon definition or for a defining word. If LATEST
has a long history, I'm not opposed to going with that.

>
>>Can the "nt" be obtained, within the framework of the standard,
>>after ":" or CREATE but not necessarily before the name becomes
>>searchable in the dictionary?
>
> No.
>

Then, a proposal for standarding LATEST (or MY-NAME) will have to require
standard implementations to ensure the availability of an "nt"
immediately after ": wordname" .

>>> FIND-NAME-IN is defined in Forth-2012 in the reference implementation
>>> of FIND-NAME-IN:
>>> <http://www.forth200x.org/reference-implementations/find-name.fs>
>>>
>>>
>>Don't we have SEARCH-WORDLIST for this?
>
> SEARCH-WORDLIST produces an xt and a number, and suffers from most of
> the problems of FIND.
>

Maybe I'm confused, but I can't find FIND-NAME-IN in the Forth-2012
standard (forth-2012.pdf). Is there an RfD for it. I assume by your
statement above that FIND-NAME-IN , unlike FIND , returns an "nt" rather
than an "xt". In that case it is distinct (and useful).

Krishna

[NN]

What about a word that takes a string and creates a header ?

eg s" plus" create-str

I would like to avoid "double parsing" the input stream.

[Krishna Myneni]

It's interesting that there is no underlying word such as CREATE-STR on
which CREATE is based. The example is INCLUDED which takes a string
argument,

s" prog1.4th" INCLUDED

and INCLUDE which parses the input stream for the file name

INCLUDE prog1.4th

In kForth INCLUDE simply parses the name and passes it as a string on the
stack to INCLUDED . I would guess that other Forths do this also.

For naming consistency, you might call the string-based creation word,
CREATED : s" plus" CREATED

CREATED may be good to have as a factor for CREATE and permits another
way of implementing defining words based on an input or computed string
rather than parsing the input stream.

Interestingly, since the concept of a named-word token (aka "name token")
is now present in the standard, from which the "xt" may be obtained via
NAME>INTERPRET , the addition of a word such as MY-NAME (or LATEST)
permits a word created with a defining word to reproduce itself. That is,
a word such as HAL in my example(s) above contains an "nt" to COMPUTER in
its data field. It may obtain the "xt" of COMPUTER and execute it. A
variant of COMPUTER which allows the created word to take an argument
from the stack to perform a function, besides just displaying its name
and the name of its creating word, can do something like the following:

REPRODUCE HAL HAL-9001

where REPRODUCE is a constant which tells HAL to reproduce itself. Having
the name token of the word that created HAL allows it to make another
computer.

Krishna Myneni

[none albert]

In article <a12c676f-e0f9-4a2d...@googlegroups.com>,

ciforth has a word like the `CREATED that Krishna proposed in another
post, called (CREATE)

: CREATE NAME (CREATE) 0804,AA82 , ;CODE plus code (suppressed) ;

All words that use NAME can be made postfix by this weird
trick^H^H^H^Htechnique that only works on Forth's where
every word can be revectored. It is called POSTFIX.

"jan" POSTFIX CREATE
has the same effect than
CREATE jan

The `NAME in `CREATE is revectored to `NAME-NEW, like so.

S[ ] OK SEE POSTFIX
: POSTFIX 'NAME-NEW >DFA @ 'NAME >DFA ! ;

`NAME-NEW just restores the normal behaviour of NAME:
: NAME-NEW 'NAME RESTORED ;

(I leave out the definition of `RESTORED because it is utterly
system dependant.)

POSTFIX works with all defining words that use `NAME, i.e.
not only `CREATE but also VARIABLE CONSTANT and : .
In ciforth this means *all* defining words.

[Alex McDonald]

On 02-Sep-19 14:31, Krishna Myneni wrote:
> On Mon, 02 Sep 2019 05:50:54 -0700, NN wrote:
>
>> What about a word that takes a string and creates a header ?
>>
>> eg s" plus" create-str
>>
>> I would like to avoid "double parsing" the input stream.
>
> It's interesting that there is no underlying word such as CREATE-STR on
> which CREATE is based. The example is INCLUDED which takes a string
> argument,
>
> s" prog1.4th" INCLUDED
>
> and INCLUDE which parses the input stream for the file name
>
> INCLUDE prog1.4th
>
> In kForth INCLUDE simply parses the name and passes it as a string on the
> stack to INCLUDED . I would guess that other Forths do this also.

Mine does, at least.

>
> For naming consistency, you might call the string-based creation word,
> CREATED : s" plus" CREATED

This can be accomplished with gforth's (and I have also) EXECUTE-PARSING.

: created ['] create execute-parsing ;

The gforth manual says:

| execute-parsing ... addr u xt – ... gforth
“execute-parsing”
| Make addr u the current input source, execute xt ( ... -- ... ), then
restore the previous input source.
|
| A definition of this word in ANS Forth is provided in
compat/execute-parsing.fs.

>
> CREATED may be good to have as a factor for CREATE and permits another
> way of implementing defining words based on an input or computed string
> rather than parsing the input stream. >
> Interestingly, since the concept of a named-word token (aka "name token")
> is now present in the standard, from which the "xt" may be obtained via
> NAME>INTERPRET , the addition of a word such as MY-NAME (or LATEST)

I use LAST, but would prefer LATEST over MY-NAME.

> permits a word created with a defining word to reproduce itself. That is,
> a word such as HAL in my example(s) above contains an "nt" to COMPUTER in
> its data field. It may obtain the "xt" of COMPUTER and execute it. A
> variant of COMPUTER which allows the created word to take an argument
> from the stack to perform a function, besides just displaying its name
> and the name of its creating word, can do something like the following:
>
> REPRODUCE HAL HAL-9001
>
> where REPRODUCE is a constant which tells HAL to reproduce itself. Having
> the name token of the word that created HAL allows it to make another
> computer.

Would you also need

KILL HAL

?


--
Alex

[Krishna Myneni]

On Mon, 02 Sep 2019 15:47:49 +0100, Alex McDonald wrote:

> On 02-Sep-19 14:31, Krishna Myneni wrote:
>> On Mon, 02 Sep 2019 05:50:54 -0700, NN wrote:
>>
>>> What about a word that takes a string and creates a header ?
>>>
>>> eg s" plus" create-str
>>>
>>> I would like to avoid "double parsing" the input stream.
>>

...

>> For naming consistency, you might call the string-based creation word,
>> CREATED : s" plus" CREATED
>
> This can be accomplished with gforth's (and I have also)
> EXECUTE-PARSING.
>
> : created ['] create execute-parsing ;
>

...

>> Interestingly, since the concept of a named-word token (aka "name
>> token")
>> is now present in the standard, from which the "xt" may be obtained via
>> NAME>INTERPRET , the addition of a word such as MY-NAME (or LATEST)
>
> I use LAST, but would prefer LATEST over MY-NAME.
>

Thanks for the data point. What do you think of the more explicit "LATEST-
NAME" ?

>> ... A

>> variant of COMPUTER which allows the created word to take an argument
>> from the stack to perform a function, besides just displaying its name
>> and the name of its creating word, can do something like the following:
>>
>> REPRODUCE HAL HAL-9001
>>
>> where REPRODUCE is a constant which tells HAL to reproduce itself.
>> Having the name token of the word that created HAL allows it to make
>> another computer.
>
> Would you also need
>
> KILL HAL
>

"KILL HAL" seems needlessly harsh, although it's accurate for the movie,
"2010". I would prefer "DIE HAL". We don't want to deal with a "CREATE
bomb" for the dictionary, much like OS's don't want to deal with a "fork
bomb".

KM

[Alex McDonald]

On 02-Sep-19 17:11, Krishna Myneni wrote:
> On Mon, 02 Sep 2019 15:47:49 +0100, Alex McDonald wrote:
>
>> On 02-Sep-19 14:31, Krishna Myneni wrote:

>>> Interestingly, since the concept of a named-word token (aka "name
>>> token")
>>> is now present in the standard, from which the "xt" may be obtained via
>>> NAME>INTERPRET , the addition of a word such as MY-NAME (or LATEST)
>>
>> I use LAST, but would prefer LATEST over MY-NAME.
>>
>
> Thanks for the data point. What do you think of the more explicit "LATEST-
> NAME" ?

I'm not a big fan of hyphenated word names. However, it's tolerable and
at least descriptive.


--
Alex

[m...@iae.nl]

On Monday, September 2, 2019 at 4:47:47 PM UTC+2, Alex McDonald wrote:
> On 02-Sep-19 14:31, Krishna Myneni wrote:
> > On Mon, 02 Sep 2019 05:50:54 -0700, NN wrote:
> >
> >> What about a word that takes a string and creates a header ?
> >>
> >> eg s" plus" create-str
> >>
> >> I would like to avoid "double parsing" the input stream.
> >

[..]

> I use LAST, but would prefer LATEST over MY-NAME.
>

[..]
> --
> Alex

FORTH> words: LAST
Split-At-LastChar-NC Split-At-LastChar
ok
FORTH> words: LATEST
SET-LATEST-LOCATION !LATEST @LATEST
ok
FORTH> help @LATEST
@LATEST IFORTH
( -- dea )
Get the dictionary entry address of the latest header that was created
in the current wordlist (the one accessed with GET-CURRENT SET-CURRENT ).
ok

Very useful word, I use it a lot when giving a user a
custom command interface.

-marcel

[Ruvim]

On 2019-09-01 19:52, Krishna Myneni wrote:
> On Sun, 01 Sep 2019 16:27:40 +0000, Anton Ertl wrote:
>
>> Krishna Myneni <krishna...@ccreweb.org> writes:
>>> Is there a proposal to standardize LATEST ?
>>
>> Not yet. Do you want to write it?
>
> Sure. I want to make sure I understand the correspondence between what I
> implemeted as MY-NAME and LATEST . I believe they are, for the most part,
> equivalent. I like "MY-NAME" since it is clear (to me) what it means when
> it is used inside of a colon definition or for a defining word. If LATEST
> has a long history, I'm not opposed to going with that.

What should it return after ':NONAME' and '[:' ? Is it the name token
for a word that was defined before, or just 0 ?



SP-Forth/4 has LATEST ( -- nt ) that returns nt for the latest added
word in the compilation wordlist (i.e. that is returned by GET-CURRENT),
and LAST ( -- addr ) that returns address that contains nt for the last
defined named word (regardless wordlists) in the current thread (since
the interpreter is multithread).

>
>>
>>> Can the "nt" be obtained, within the framework of the standard,
>>> after ":" or CREATE but not necessarily before the name becomes
>>> searchable in the dictionary?
>>
>> No.
>>
>
> Then, a proposal for standarding LATEST (or MY-NAME) will have to require
> standard implementations to ensure the availability of an "nt"
> immediately after ": wordname" .

In some Forth systems it can be difficult to define MY-NAME since the
header is created not by ':', but by ';' (rationale: no need for HIDE
and REVEAL or SMUDGE words).


--
Ruvim

[Alex McDonald]

On 02-Sep-19 21:49, Ruvim wrote:
> On 2019-09-01 19:52, Krishna Myneni wrote:
>>
>> Sure. I want to make sure I understand the correspondence between what I
>> implemeted as MY-NAME and LATEST . I believe they are, for the most part,
>> equivalent. I like "MY-NAME" since it is clear (to me) what it means when
>> it is used inside of a colon definition or for a defining word. If LATEST
>> has a long history, I'm not opposed to going with that.
>
>
> What should it return after ':NONAME' and '[:' ? Is it the name token
> for a word that was defined before, or just 0 ?

The last named word. There are lost of good reasons not to return 0 in
this circumstance, e.g. for the building of unnamed table entries:

: named ;
:noname [ latest ( should be of <named> ) ... ;

Plus, LATESTXT should be pushed on the control stack at [: and popped at ;]



--
Alex

[Krishna Myneni]

On Mon, 02 Sep 2019 11:01:39 -0700, mhx wrote:

> On Monday, September 2, 2019 at 4:47:47 PM UTC+2, Alex McDonald wrote:

...

>> I use LAST, but would prefer LATEST over MY-NAME.
>>

...

>
> FORTH> words: LAST Split-At-LastChar-NC Split-At-LastChar
> ok
> FORTH> words: LATEST SET-LATEST-LOCATION !LATEST @LATEST
> ok
> FORTH> help @LATEST @LATEST
> IFORTH
> ( -- dea )
> Get the dictionary entry address of the latest header that was
> created in the current wordlist (the one accessed with GET-CURRENT
> SET-CURRENT ).
> ok
>
> Very useful word, I use it a lot when giving a user a custom command
> interface.
>
> -marcel

The current list of possible names for a word to retrieve the "nt" of the
current/last dictionary entry, with no significance attached to ordering,
are :

LATEST
LATEST-NAME
@LATEST
LAST
MY-NAME

In iForth, is "dea" equivalent to an "nt" in the sense that you have
words corresponding to NAME>STRING , NAME>INTERPRET , and NAME>COMPILE
which act on the "dea"? Or are these operations not possible with just
the "dea" as the argument?

Krishna

[Krishna Myneni]

On Mon, 02 Sep 2019 23:49:55 +0300, Ruvim wrote:

> On 2019-09-01 19:52, Krishna Myneni wrote:
>> On Sun, 01 Sep 2019 16:27:40 +0000, Anton Ertl wrote:
>>
>>> Krishna Myneni <krishna...@ccreweb.org> writes:
>>>> Is there a proposal to standardize LATEST ?
>>>

...

>
> What should it return after ':NONAME' and '[:' ? Is it the name token
> for a word that was defined before, or just 0 ?

LATEST or other possible synonyms should return the most recent "nt",
which stands for named-word token; hence, when it is used within
a :NONAME definition or after one, by virtue of a :NONAME definition
being for an un-named word. The "nt" of the most recent named-word should
be returned.

>
>
> SP-Forth/4 has LATEST ( -- nt ) that returns nt for the latest added
> word in the compilation wordlist (i.e. that is returned by GET-CURRENT),
> and LAST ( -- addr ) that returns address that contains nt for the last
> defined named word (regardless wordlists) in the current thread (since
> the interpreter is multithread).
>

In the single thread case, what happens if you do the following in SP-
Forth?

---
wordlist constant New-Wordlist

: word1 ( ... ) ;

New-Wordlist set-current

latest
---

Does LATEST retrieve the "nt" for WORD1 or a null value?


>> A proposal for standarding LATEST (or MY-NAME) will have to

>> require standard implementations to ensure the availability of an "nt"
>> immediately after ": wordname" .
>
>
> In some Forth systems it can be difficult to define MY-NAME since the
> header is created not by ':', but by ';' (rationale: no need for HIDE
> and REVEAL or SMUDGE words).

For those systems, I don't see a way to implement LATEST (or synonym)
since one of its major uses is within a colon definition to obtain the
"nt" for the word being defined. We will have to discuss whether or not
the standard wishes to tighten up the order in which the internal word
header must be created. It will be helpful to know which Forth systems in
particular will not be able to do this.

Krishna Myneni

[dxforth]

:noname certainly present some challenges e.g. you want to avoid IMMEDIATE
if executed not to affect the wrong word. This usually means giving
:nonames a dummy nfa.

[m...@iae.nl]

I don't give or choose names I really like to words I suspect
will once appear in the standard because I can be sure the name
will be changed :-)

> In iForth, is "dea" equivalent to an "nt" in the sense that you have
> words corresponding to NAME>STRING , NAME>INTERPRET , and NAME>COMPILE
> which act on the "dea"? Or are these operations not possible with just
> the "dea" as the argument?

There are words to go from the dea to *any other* field.
There are also words to go from these other fields to
*almost any* other field, although in less common cases
it could be a multi-hop experience. One thing that is
not possible is to go from an xt to the dea (because
for optimized compiled code an xt does not appear
in the compiled code). For introspection, nothing
beats the dea.

As all things Forth go, most requests are for what is
impossible: xt to dea. A workaround is to redefine
the word is question and give it the attribute
"not optimizing" ( "[]" somewhere in the definition).
A relative CALL to an xt is detectable with special
search words.

-marcel

[Anton Ertl]

m...@iae.nl writes:
>One thing that is
>not possible is to go from an xt to the dea (because
>for optimized compiled code an xt does not appear
>in the compiled code).

While I expect that there are Forth systems where an xt -> nt
conversion is not possible, I have problems following your
explanation. Of course a Forth compiler may compile, say, + into an
add instruction that has no relation to the xt, there still has to be
an xt for +, and you can get it with "' +". Whether you can get the
nt from this xt is a different question.

[Anton Ertl]

Krishna Myneni <krishna...@ccreweb.org> writes:
>On Mon, 02 Sep 2019 23:49:55 +0300, Ruvim wrote:

...

>LATEST or other possible synonyms should return the most recent "nt",
>which stands for named-word token; hence, when it is used within
>a :NONAME definition or after one, by virtue of a :NONAME definition
>being for an un-named word. The "nt" of the most recent named-word should
>be returned.

In Gforth, we have:

LATEST ( -- nt|0 )

nt for a named word, 0 for an unnamed word.

After fixing the LATESTXT bug, we now also have:

LATESTNT ( -- nt )

for all words (unnamed words now have nts).

In no case do you get the nt of the last named word if there is an
unnamed word defined with :NONAME and NONAME in between.

But [:...;] can be used interpretively, and restore LATEST, LATESTNT,
and LATESTXT.

: foo ;
[: [ latest . \ prints 0
] ;] drop
latest name>string type \ prints foo

>> In some Forth systems it can be difficult to define MY-NAME since the
>> header is created not by ':', but by ';' (rationale: no need for HIDE
>> and REVEAL or SMUDGE words).

HIDE is unnecessary. REVEAL (insertion into the current wordlist) is
necessary in any case.

If you only build the header at ";", you have to remember the name and
xt until ";". I find it hard to believe that anybody would choose
that, but you can surprise me by telling us which Forth systems work
that way.

[Anton Ertl]

Alex McDonald <al...@rivadpm.com> writes:
>On 02-Sep-19 21:49, Ruvim wrote:
>> What should it return after ':NONAME' and '[:' ? Is it the name token
>> for a word that was defined before, or just 0 ?
>
>The last named word. There are lost of good reasons not to return 0 in
>this circumstance, e.g. for the building of unnamed table entries:
>
>: named ;
>:noname [ latest ( should be of <named> ) ... ;

Your example demonstrates what you want to see, but not a good
reason for your preference.

I don't remember ever wishing for a different behaviour of LATEST in
Gforth (which returns 0 in your example); obviously I have always
found a way to do what I want without the feature you want. For your
example, I guess I would write

: named ;
:noname [ ' named ... ;

In Gforth LATEST has returned 0 after :NONAME since 0.6.2 (2003), and
nobody has complained about that; likewise, since Gforth was first
released in 1996 (0.2.1), LAST @ returned 0 after :NONAME, and nobody
has complained about that.

[Alex McDonald]

On 03-Sep-19 12:07, Anton Ertl wrote:
> Alex McDonald <al...@rivadpm.com> writes:
>> On 02-Sep-19 21:49, Ruvim wrote:
>>> What should it return after ':NONAME' and '[:' ? Is it the name token
>>> for a word that was defined before, or just 0 ?
>>
>> The last named word. There are lost of good reasons not to return 0 in
>> this circumstance, e.g. for the building of unnamed table entries:
>>
>> : named ;
>> :noname [ latest ( should be of <named> ) ... ;
>
> Your example demonstrates what you want to see, but not a good
> reason for your preference.
>
> I don't remember ever wishing for a different behaviour of LATEST in
> Gforth (which returns 0 in your example); obviously I have always
> found a way to do what I want without the feature you want. For your
> example, I guess I would write
>
> : named ;
> :noname [ ' named ... ;

That is why I use LATEST (actually, my LAST) because the name isn't
known while processing :NONAME. It's a generic piece of code that's
included repeatedly after named words are defined.

>
> In Gforth LATEST has returned 0 after :NONAME since 0.6.2 (2003), and
> nobody has complained about that; likewise, since Gforth was first
> released in 1996 (0.2.1), LAST @ returned 0 after :NONAME, and nobody
> has complained about that.

I won't complain if LATEST does as you suggest, but I will then continue
to use LAST. Since my use case isn't standard compliant, that's fine.



--
Alex

[Alex McDonald]

I have all :NONAMEs and [: point at a single header ANONYMOUS which is
not FINDable (it's smudged). It simplifies & makes more consistent much
of the NT processing where it's possible to go from XT to NT.

:NONAME ; >NAME NAME>INTERPRET ( or NAME>COMPILE )

returns an abort to make sure there's no opportunity to abuse the XT
found by the XT -> NT -> XT route.

IMMEDIATE on the other hand works on the last named XT, not on anonymous
XTs. This is permitted, as is your approach, because of a documented
ambiguity.

IMMEDIATE
( -- )
Make the most recent definition an immediate word. An ambiguous
condition exists if the most recent definition does not have a name or
if it was defined as a SYNONYM.

--
Alex

[Alex McDonald]

In fact, thinking about it;

: named [: ( unnamed ) ;] ; immediate

Your approach would make IMMEDIATE the wrong thing. Perhaps that should
be noted in the standard and the ambiguity removed.

--
Alex

[Krishna Myneni]

On Tue, 03 Sep 2019 07:19:33 +0000, Anton Ertl wrote:

> Krishna Myneni <krishna...@ccreweb.org> writes:
>>On Mon, 02 Sep 2019 23:49:55 +0300, Ruvim wrote:
> ...
>>LATEST or other possible synonyms should return the most recent "nt",
>>which stands for named-word token; hence, when it is used within a
>>:NONAME definition or after one, by virtue of a :NONAME definition being
>>for an un-named word. The "nt" of the most recent named-word should be
>>returned.
>
> In Gforth, we have:
>
> LATEST ( -- nt|0 )
>
> nt for a named word, 0 for an unnamed word.
>

Apparently I misunderstood the meaning of LATEST in Gforth.

> After fixing the LATESTXT bug, we now also have:
>
> LATESTNT ( -- nt )
>
> for all words (unnamed words now have nts).
>

This behavior contradicts the Forth 2012 standard:

15.3.1 Data types
A name token is a single-cell value that identifies a named word.

Krishna Myneni

[dxforth]

On Tuesday, 3 September 2019 22:03:08 UTC+10, Alex McDonald wrote:
> ...

> IMMEDIATE
> ( -- )
> Make the most recent definition an immediate word. An ambiguous
> condition exists if the most recent definition does not have a name or
> if it was defined as a SYNONYM.

Hopefully 'ambiguous' here means the response taken to the error - not
whether it is one. Several popular forths will happily set the named
word in the following example to immediate.

: foo ;
:noname ;
immediate

That's an oversight - not a feature :)

[dxforth]

On Tuesday, 3 September 2019 22:09:17 UTC+10, Alex McDonald wrote:
> ...

> In fact, thinking about it;
>
> : named [: ( unnamed ) ;] ; immediate
>
> Your approach would make IMMEDIATE the wrong thing. Perhaps that should
> be noted in the standard and the ambiguity removed.

Another reason not to use quotations :)

[Ruvim]

On 2019-09-03 08:41, m...@iae.nl wrote:
[...]

> As all things Forth go, most requests are for what is
> impossible: xt to dea. A workaround is to redefine
> the word is question and give it the attribute
> "not optimizing" ( "[]" somewhere in the definition).
> A relative CALL to an xt is detectable with special
> search words.

By my experience this operation is used for debug only.
Therefore, it may be slow. E.g., it can enumerate all the words (from
all wordlists) and match xt.


SP-Forth has word WordByAddr [1] that finds name by any address
(it may be xt or any other address in the compiled code).

Certainly, if several nt refer to the same xt, only the first one will
be found (in the order of enumerating).


[1]
https://github.com/rufig/spf4-utf8/blob/master/src/compiler/spf_wordlist.f#L210


--
Ruvim

[Ruvim]

On 2019-09-03 02:34, Krishna Myneni wrote:
> On Mon, 02 Sep 2019 23:49:55 +0300, Ruvim wrote:
>> On 2019-09-01 19:52, Krishna Myneni wrote:
>>> On Sun, 01 Sep 2019 16:27:40 +0000, Anton Ertl wrote:
>>>
>>>> Krishna Myneni <krishna...@ccreweb.org> writes:
>>>>> Is there a proposal to standardize LATEST ?
>>>>

> ....

>>
>> What should it return after ':NONAME' and '[:' ? Is it the name token
>> for a word that was defined before, or just 0 ?
>
> LATEST or other possible synonyms should return the most recent "nt",
> which stands for named-word token; hence, when it is used within
> a :NONAME definition or after one, by virtue of a :NONAME definition
> being for an un-named word. The "nt" of the most recent named-word should
> be returned.
>
>> SP-Forth/4 has LATEST ( -- nt ) that returns nt for the latest added
>> word in the compilation wordlist (i.e. that is returned by GET-CURRENT),
>> and LAST ( -- addr ) that returns address that contains nt for the last
>> defined named word (regardless wordlists) in the current thread (since
>> the interpreter is multithread).
>>
>
> In the single thread case, what happens if you do the following in SP-
> Forth?
>
> ---
> wordlist constant New-Wordlist
>
> : word1 ( ... ) ;
>
> New-Wordlist set-current
>
> latest
> ---
>
> Does LATEST retrieve the "nt" for WORD1 or a null value?

It returns 0 in this case, since the compilation wordlist does not
contain any word at all.


Another issue is that in some Forth systems the name of the current
definition is garbled (to be unfindable).

So, it is ambiguous to apply NAME>STRING to nt of the current definition
(even if this nt can be obtained).

>>> A proposal for standarding LATEST (or MY-NAME) will have to
>>> require standard implementations to ensure the availability of an "nt"
>>> immediately after ": wordname" .
>>
>>
>> In some Forth systems it can be difficult to define MY-NAME since the
>> header is created not by ':', but by ';' (rationale: no need for HIDE
>> and REVEAL or SMUDGE words).
>
> For those systems, I don't see a way to implement LATEST (or synonym)
> since one of its major uses is within a colon definition to obtain the
> "nt" for the word being defined.

Also, it could already have LATEST that returns nt for the last defined
word but not for the current definition (i.e. the word being defined).

> We will have to discuss whether or not
> the standard wishes to tighten up the order in which the internal word
> header must be created. It will be helpful to know which Forth systems in
> particular will not be able to do this.

The Standard cannot require a specific order since there is no a
standard way to detect this order. It just says that the current
definition cannot be found:

| The current definition shall not be findable in the dictionary
| until it is ended (or until the execution of DOES> in some systems).


So, it will be (if any) the new requirement.


--
Ruvim

[Alex McDonald]

By prefixing the XT with a cell containing a pointer (or as in the
example, a relative offset) to the NT, getting from XT to NT doesn't
require an exhaustive search. (CT is a fixed offset from the NT.)

: >ct ( xt -- ct ) dup cell- @ + ;
: >name ( xt -- nt ) >ct [ 0 head.nt 0 head.ct - ] literal + ;

To search (NFA is name field address, CDP 2@ is the bounds of the code
area) by TRAVERSE-WORDLISTing over all the wordlists via LIST-APPLY (an
iterator over a list);

\ Given a possible address somewhere in an xt, tries to find the nearest nfa
\ by searching all the wordlists; returns the nfa in the header or zero.
\ The best is the lowest that's >= to the supplied address.

: best-addr ( addr best-xt nfa -- addr best-xt' true )
name>interpret rot dup>r over \ ( a b x -> b x a x r: a )
>= if max else drop then
r> swap true ;

: code>name ( addr -- nfa | 0 )
dup cdp 2@ between 0= if \ origin + highest addr for section
drop 0 \ it's zero if not in a code section
else
0 \ ( addr best-xt )
voc-link @ \ iterate vocabs
[: ['] best-addr swap \ find closest xt
traverse-wordlist ;] \ traverse wordlist
list-apply nip >name
then ;




--
Alex

[Ruvim]

On 2019-09-03 10:19, Anton Ertl wrote:
> Krishna Myneni <krishna...@ccreweb.org> writes:
>> On Mon, 02 Sep 2019 23:49:55 +0300, Ruvim wrote:

[...]

>>> In some Forth systems it can be difficult to define MY-NAME since the
>>> header is created not by ':', but by ';' (rationale: no need for HIDE
>>> and REVEAL or SMUDGE words).
>
> HIDE is unnecessary. REVEAL (insertion into the current wordlist) is
> necessary in any case.

I saw the following definitions:

HIDE ( -- )
Make the last defined entry invisible, if it is possible.

REVEAL ( -- )
Make the last defined entry visible, does nothing if HIDE does so.

See also the reference implementation for SYNONYM in Forth-2012 [1]
It uses REVEAL in this sense too.

>
> If you only build the header at ";", you have to remember the name and
> xt until ";". I find it hard to believe that anybody would choose
> that, but you can surprise me by telling us which Forth systems work
> that way.

Yes, they are remembered.

I used such API [2]

The idea is to separate the concerns: separate the code generator from
the names management.

The code generator produces XTs only and knows nothing about NT, names
and wordlists.

The names management knows nothing about XTs but it is responsible for
naming (keeping key-value pairs), wordlists, search order, names
resolving, etc. Therefore, it can be used not only XTs, but for any
one-cell values.


[1] https://forth-standard.org/standard/tools/SYNONYM
[2]
https://github.com/rufig/spf4-utf8/blob/master/devel/%7Epinka/spf/compiler/native-wordlist.f


--
Ruvim

[m...@iae.nl]

On Tuesday, September 3, 2019 at 9:19:17 AM UTC+2, Anton Ertl wrote:
> m...@iae.nl writes:
> >One thing that is
> >not possible is to go from an xt to the dea (because
> >for optimized compiled code an xt does not appear
> >in the compiled code).
>
> While I expect that there are Forth systems where an xt -> nt
> conversion is not possible, I have problems following your
> explanation. Of course a Forth compiler may compile, say, + into an
> add instruction that has no relation to the xt, there still has to be
> an xt for +, and you can get it with "' +". Whether you can get the
> nt from this xt is a different question.

What users with the "xt->nt" request actually want is to decompile
(on their own) a colon definition, expecting to find cell shaped
objects that were ","-ed there. A good example is the Brainless
program. In iForth compile,-ing an xt does not normally result
in a simple CALL. The generated code can not be found anywhere or
"near" something because it is generated on the fly and not
copied from a fixed location.

-marcel

[hughag...@gmail.com]

You should use the term "Paysan-Faked Quotation" rather than "quotation" here.
The Paysan-Faked Quotation is just syntactic sugar for :NONAME --- this is not
an actual quotation.

[Anton Ertl]

Ruvim <ruvim...@gmail.com> writes:
>On 2019-09-03 10:19, Anton Ertl wrote:
>> Krishna Myneni <krishna...@ccreweb.org> writes:
>>> On Mon, 02 Sep 2019 23:49:55 +0300, Ruvim wrote:
>[...]
>>>> In some Forth systems it can be difficult to define MY-NAME since the
>>>> header is created not by ':', but by ';' (rationale: no need for HIDE
>>>> and REVEAL or SMUDGE words).
>>
>> HIDE is unnecessary. REVEAL (insertion into the current wordlist) is
>> necessary in any case.
>
>
>I saw the following definitions:
>
> HIDE ( -- )
> Make the last defined entry invisible, if it is possible.
>
> REVEAL ( -- )
> Make the last defined entry visible, does nothing if HIDE does so.
>
>See also the reference implementation for SYNONYM in Forth-2012 [1]
>It uses REVEAL in this sense too.

This implementation is specific to VFX (as mentioned in the text). It
uses CREATE, which REVEALs the new word, and then HIDEs it again to
find the old word, and finally REVEALs the new word again.

Gforth's SYNONYM implementation currently looks as follows:

: Synonym ( "name" "oldname" -- ) \ Forth200x
header dodefer,
?parse-name find-name dup 0= #-13 and throw
dup compile-only? IF compile-only THEN
['] s>int ['] s>comp synonym, reveal ;

This creates the word with HEADER (which does not REVEAL it), then
FIND-NAMEs the old word, and eventually REVEALs the new word. Gforth
does not have HIDE, and we have not missed it yet.

[Anton Ertl]

m...@iae.nl writes:
>What users with the "xt->nt" request actually want is to decompile
>(on their own) a colon definition,

Looking at the uses of >NAME in the Gforth source code, I indeed find
that most of them are in the decompiler.

>expecting to find cell shaped
>objects that were ","-ed there.

I think, though, that the uses in the Gforth decompiler are to get the
name for the address that came out of earlier stages of the
decompiler.

Other uses are in profiling code (to print the names of the profiled
words), and in other introspection code.

>A good example is the Brainless
>program.

Interesting. It works on Gforth, bigForth and VFX, which do not just
use "," for compilation, either.

[hughag...@gmail.com]

On Tuesday, September 3, 2019 at 11:15:11 AM UTC-7, Anton Ertl wrote:

> Ruvim <ruvim...@gmail.com> writes:
> >I saw the following definitions:
> >
> > HIDE ( -- )
> > Make the last defined entry invisible, if it is possible.
> >
> > REVEAL ( -- )
> > Make the last defined entry visible, does nothing if HIDE does so.
> >
> >See also the reference implementation for SYNONYM in Forth-2012 [1]
> >It uses REVEAL in this sense too.
>
> This implementation is specific to VFX (as mentioned in the text). It
> uses CREATE, which REVEALs the new word, and then HIDEs it again to
> find the old word, and finally REVEALs the new word again.
>
> Gforth's SYNONYM implementation currently looks as follows:
>
> : Synonym ( "name" "oldname" -- ) \ Forth200x
> header dodefer,
> ?parse-name find-name dup 0= #-13 and throw
> dup compile-only? IF compile-only THEN
> ['] s>int ['] s>comp synonym, reveal ;
>
> This creates the word with HEADER (which does not REVEAL it), then
> FIND-NAMEs the old word, and eventually REVEALs the new word. Gforth
> does not have HIDE, and we have not missed it yet.

SYNONYM SYNONYM-FAST and ALIAS are trivial to implement in ANS-Forth
given that the disambiguifiers are already provided:
-----------------------------------------------------------------------
\ ******
\ ****** Our SYNONYM SYNONYM-FAST and ALIAS words --- these depend upon having the disambiguifiers available.
\ ******

: :synonym { xt flg str wid -- } \ FLG is 1 for immediate and -1 for non-immediate
str wid :name
flg 1 = if xt lit, execute, ;, immediate exit then
flg -1 = if xt compile, ;, exit then
true abort" *** :SYNONYM given an invalid xt ***" ;

: :synonym-fast-check ( -- )
state @ 0= abort" *** a word created by :SYNONYM-FAST can't be used in interpretive mode ***" ;

: :synonym-fast { xt flg str wid -- } \ FLG is 1 for immediate and -1 for non-immediate
str wid :name
flg 1 = if xt lit, execute, ;, immediate exit then
flg -1 = if postpone :synonym-fast-check
xt lit, postpone compile, ;, immediate exit then
true abort" *** :SYNONYM-FAST given an invalid xt ***" ;

: 'find ( -- xt flg ) \ stream: name \ FLG is 1 for immediate and -1 for non-immediate
bl word find dup 0= abort" *** 'FIND couldn't find the word ***" ;

: synonym { wid | new -- } \ stream: new-name old-name \ the new word is compiled into the WID word-list
bl word hstr to new
'find new wid :synonym
new dealloc ;

: synonym-fast { wid | new -- } \ stream: new-name old-name \ the new word is compiled into the WID word-list
bl parse <hstr> to new
'find new wid :synonym-fast
new dealloc ;

\ :SYNONYM-FAST generates faster executing code than :SYNONYM but the words can't be used in interpretive mode.
\ This may not be necessary with a good optimizing compiler, but I'm not aware of any at this time.

1234512345 constant alias-id \ an arbitrary number used to identify alias'd definitions

0
w field alias.xt \ this should be the first field so the DOES> portion of ALIAS will be fast (no addition needed)
w field alias.adr \ the address of the body, used to identify alias'd definitions
w field alias.id \ the constant ALIAS-ID, used to identify alias'd definitions
constant alias-struct

: alias ( wid -- ) \ stream: new-name old-name \ the new word is compiled into the WID word-list
get-current swap set-current create set-current
here >r alias-struct allot
'find 1 = if immediate then r@ alias.xt !
r@ r@ alias.adr !
alias-id r@ alias.id !
rdrop
does>
alias.xt @ execute ;

\ ALIAS does the same thing as SYNONYM but has the advantage that ' ['] and >BODY will work on it.
\ It is slower executing though (especially under SwiftForth in which CREATE DOES> words are very inefficient).

: ' ( -- xt ) \ stream: name
' \ -- xt
dup >body >r
r@ alias.adr @ r@ = if r@ alias.id @ alias-id = if \ is this an alias'd word?
drop r> alias.xt @ exit then then \ return the xt of the original word
rdrop ;

: ['] ( -- ) \ stream: name \ runtime: -- xt
' postpone literal ; immediate

: >body ( xt -- adr )
>body >r
r@ alias.adr @ r@ = if r@ alias.id @ alias-id = if \ is this an alias'd word?
r> alias.xt @ >body exit then then \ return the body of the original word
r> ; \ return the body of this word

\ Note that >BODY still has an undefined result if used on a word that wasn't defined with CREATE or isn't an alias of such a word.
-----------------------------------------------------------------------

[Alex McDonald]

: synonym ( -<newname> <oldname>- )
header hide
definite-find \ -13 throw if not found
name>interpret ['] execute if immediate then
xtc! reveal ; \ xtc! set the xt in the header



--
Alex

[hughag...@gmail.com]

On Tuesday, September 3, 2019 at 11:28:53 AM UTC-7, Anton Ertl wrote:
> m...@iae.nl writes:
> >What users with the "xt->nt" request actually want is to decompile
> >(on their own) a colon definition,
>
> Looking at the uses of >NAME in the Gforth source code, I indeed find
> that most of them are in the decompiler.

I have this in the novice-package:
-----------------------------------------------------------------------
VFX? [if] \ We have >NAME so error-checking will be done. This code may work in other ANS-Forth systems as well.

: in-wordlist? ( xt wid -- 0|1|-1 ) \ we return 0 for not-found, 1 for immediate and -1 for non-immediate
over >name count rot search-wordlist \ -- xt 0 | xt found-xt 1 | xt found-xt -1
>r
r@ 0= if drop r> exit then \ it wasn't found
= if r> exit then \ it was found and it is the same
r> drop 0 ; \ it was found but it wasn't the same (it had the same name, but was a different word)

[else] \ We can't be sure that >NAME will be available except in VFX, so error-checking won't be done.

: in-wordlist? ( xt wid -- 0|1|-1 )
true abort" *** IN-WORDLIST? is not available except in VFX" ;
immediate

[then]
-----------------------------------------------------------------------

This is used for debugging in the cross-compiler.
In my experience, the most common source of bugs is to use an xt
believing it to have come from one word-list when it is from another.
This can happen because almost all of the words have two versions
with the same name --- one TARG version and one HOST version.
The HOST version is automatically generated --- it is immediate and it
compiles a call to the TARG version --- this is what gets found and
executed by the outer-interpreter inside of a TARG colon word.

The fact that >NAME was not included in the ANS-Forth standard implies
that nobody on the ANS-Forth committee knew anything about Forth
cross-compilers. I don't think anybody on the Forth-200x committee
knows anything about this important subject either.

[Alex McDonald]

On 03-Sep-19 19:36, Alex McDonald wrote:

>
> : synonym ( -<newname> <oldname>- )
>     header hide
>     definite-find   \ -13 throw if not found
> name>interpret ['] execute if immediate then

dup name>interpret ['] execute if immediate then

>     xtc! reveal ;   \ xtc! set the xt in the header
>

A DUP got nipped during cut&paste.


--
Alex

[Krishna Myneni]

Ok. This is different from the current implementation of LATEST (in
Gforth) and MY-NAME (in kForth) which return the "nt" for the last word
defined, even if it is not in the current compilation wordlist. Which of
these two behaviors is actually more useful can be debated. I don't have
a conclusion on this matter yet.

>
> Another issue is that in some Forth systems the name of the current
> definition is garbled (to be unfindable).

What's the purpose of making it unfindable in that manner? The idea
behind MY-NAME is that no search need be performed -- the system is
assumed to know the "nt" of the word that it is currently compiling.

>
> So, it is ambiguous to apply NAME>STRING to nt of the current definition
> (even if this nt can be obtained).

I assume that when the word is finished being compiled, the name is
ungarbled so that it can be searched. In that case NAME>STRING can still
get a valid name, provided NAME>STRING is not a compiling word.

...

>
> Also, it could already have LATEST that returns nt for the last defined
> word but not for the current definition (i.e. the word being defined).
>

We may have two different functionalities that need two separate words:
one to work inside of a colon definition to return the "nt" of an
incompletely compiled word, and another word to return the "nt" of a
searchable word. In this case MY-NAME is well-named for the former
function while LATEST is descriptive for the latter function.

>
>
>> We will have to discuss whether or not the standard wishes to tighten
>> up the order in which the internal word header must be created. It will
>> be helpful to know which Forth systems in particular will not be able
>> to do this.
>
> The Standard cannot require a specific order since there is no a
> standard way to detect this order. It just says that the current
> definition cannot be found:
>
> | The current definition shall not be findable in the dictionary | until
> it is ended (or until the execution of DOES> in some systems).
>
>
> So, it will be (if any) the new requirement.

Yes, that's the rationale behind standardizing a new word which can
obtain the "nt" for an incompletely compiled word.

Krishna

[Ruvim]

Hence we have:

XXX ( -- nt ) or ( -- nt|0 )
~~~ return nt for the last definition


If somebody still want to design a specification for this word, the
following question should be definite:


In what domain the definition should be the last one?
- the last defined in the current wordlist?
- the last defined from the Forth system or current thread start
(the most recent definition)?

Should it take into account the nameless definitions?
(i.e. may a nameless definition be the last definition)
If yes, what to return if the last definition is nameless?
NB: in some systems it can have nt nevertheless.

Should it take into account the current definition (if it exists)?
(i.e. may the current definition be the last definition)
NB: it can be nameless.
NB: for some systems, even nt can be obtained for the current
definition, NAME>* words can return incorrect (or not final)
result while compilation of this definition is not ended.

What definition is the last one?
NB: in some systems a definition can be bound to an arbitrary name
in an arbitrary wordlist as a separate independent operation
(even many times) and the new nt is created on that.
Should this operation change the result of XXX?
NB: in some systems new nt can be created for the local variables
and quotations too (i.e., they are definitions).

What to return if the last definition is absent? Should it return the
predefined nt-null (that is not null) in such case, or just 0?

May the returned nt be unreachable via TRAVERSE-WORDLIST?


--
Ruvim

[Krishna Myneni]

On Wed, 04 Sep 2019 02:01:45 +0300, Ruvim wrote:

...

> Hence we have:
>
> XXX ( -- nt ) or ( -- nt|0 )
> ~~~ return nt for the last definition
>
>

...

> Should it take into account the nameless definitions?
> (i.e. may a nameless definition be the last definition)
> If yes, what to return if the last definition is nameless?
> NB: in some systems it can have nt nevertheless.
>

Logically, no, a nameless definition cannot have an "nt", since, per the
Forth-2012 standard, the "nt" is defined as a token to a named word. If
we want to call it a "word token" to encompass both named and unnamed
words, that's fine.

Krishna

[dxforth]

So you need to define what is a quotation. If the critical requirement be it
must access parent's locals then that's do-able using :noname and maybe it
doesn't need locals of its own (quotations should never be that complicated
- or so I've been told).

\ Quotations
\ Load before locals to give quotations access to parent locals
system
: [: ( c: -- q-sys )
state @ if
last 2@ postpone ahead bal @ csp @ true
else false then :noname ; immediate

: ;] ( c: q-sys -- ; -- | xt )
postpone ; >r if
csp ! bal ! ] postpone then last 2!
r> postpone literal
end r> ( xt ) ; immediate
application

[Ruvim]

On 2019-09-04 02:07, Krishna Myneni wrote:
> On Wed, 04 Sep 2019 02:01:45 +0300, Ruvim wrote:
>

> ....

>> Hence we have:
>>
>> XXX ( -- nt ) or ( -- nt|0 )
>> ~~~ return nt for the last definition
>>
>>

> ....

>> Should it take into account the nameless definitions?
>> (i.e. may a nameless definition be the last definition)
>> If yes, what to return if the last definition is nameless?
>> NB: in some systems it can have nt nevertheless.
>>
>
> Logically, no, a nameless definition cannot have an "nt", since, per the
> Forth-2012 standard, the "nt" is defined as a token to a named word.

1. The Standard does not prohibit to create "nt" for a definition that
is created via ':NONAME'.

E.g. Gforth creates "nt" with zero-length name for such definition, and
this behavior does not violate the Standard.

For that reason IMMEDIATE may work for such definition in a standard
system. But a standard program cannot rely on this feature.

Remember: there are two sides: "program" and "system", and the
requirements and limitations are different for them.


2. Your reasoning is not relevant to the question. Since "last
definition" term can be defined in such a way that a nameless definition
can be the last definition too. And the options for XXX in this case are
the following:
— it should return 0
— it should return nt-null
— it may return nt (if the system supports it) or 0.
— it may return nt (if the system supports it) or nt-null.

> If we want to call it a "word token" to encompass both named and unnamed
> words, that's fine.

If a name is zero-length, is it a named or an unnamed word?


--
Ruvim

[Anton Ertl]

Ruvim <ruvim...@gmail.com> writes:
>Hence we have:
>
>XXX ( -- nt ) or ( -- nt|0 )
> ~~~ return nt for the last definition
>
>
>If somebody still want to design a specification for this word, the
>following question should be definite:
>
>
>In what domain the definition should be the last one?
> - the last defined in the current wordlist?
> - the last defined from the Forth system or current thread start
> (the most recent definition)?

fig-Forth's LATEST produces the former. Gforth's LATEST produces the
latter. Nobody has complained about that, so one option is to leave
it open (e.g., by making it an ambiguous condition).

If we want to avoid such looseness, I obviously think that the latter
is preferable.

>Should it take into account the nameless definitions?
>(i.e. may a nameless definition be the last definition)
>If yes, what to return if the last definition is nameless?
> NB: in some systems it can have nt nevertheless.

In Gforth LATEST returns 0 if the last definition is nameless, and the
very recent LATESTNT returns the nt of that definition.

In SwiftForth LAST @ returns 0 if the last definition is nameless.

In VFX LATEST returns the address of the control field of the last
named definition (note that thus address does not serve as nt; you
have to write LATEST CTRL>NFA to get the nt).

Interestingly, in VFX even LATEST-XT returns the xt of the last named
word (even if there is a later :NONAME), while in Gforth LATESTXT
returns the xt of the latest word whether named or not.

>Should it take into account the current definition (if it exists)?
>(i.e. may the current definition be the last definition)
> NB: it can be nameless.
> NB: for some systems, even nt can be obtained for the current
> definition, NAME>* words can return incorrect (or not final)
> result while compilation of this definition is not ended.

That question is unclear to me. What, if not the last definition, do
you mean with "current definition".

>What definition is the last one?
> NB: in some systems a definition can be bound to an arbitrary name
> in an arbitrary wordlist as a separate independent operation
> (even many times) and the new nt is created on that.
> Should this operation change the result of XXX?

As long as these capabilities are not standardized, it is up to the
system how it affects the operation of LATEST.

Gforth has

MAKE-LATEST ( nt -- )

which makes nt the "last definition" as far as words referring to the
last definition are concerned, such as LATEST or IMMEDIATE.

> NB: in some systems new nt can be created for the local variables
> and quotations too (i.e., they are definitions).

That's the case in Gforth, but the previous LATEST etc. is restored
when the locals or quotation definition ends:

: foo \ compiled
[ latest hex. ] \ $7F610CF9E888 compiled
{: a :} [ latest hex. ] \ $7F610CF9E888 compiled
[: [ latest hex. ] ;] \ $0 compiled
[ latest hex. ] ; \ $7F610CF9E888 ok

>What to return if the last definition is absent? Should it return the
>predefined nt-null (that is not null) in such case, or just 0?

In Gforth, if you call LATEST before defining a word, it returns the
last word defined by the system before the image was saved. The same
seems to be the case for VFX.

>May the returned nt be unreachable via TRAVERSE-WORDLIST?

In Gforth, it certainly is before the word is REVEALed. E.g., in the
definition of FOO above, FOO is only REVEALed at ";", but LATEST
returns the nt earlier.

- anton

[Anton Ertl]

Ruvim <ruvim...@gmail.com> writes:
>In what domain the definition should be the last one?
> - the last defined in the current wordlist?
> - the last defined from the Forth system or current thread start
> (the most recent definition)?

This question is related to how to deal with words between : and ;.
There are two common options:

SMUDGE: The word is inserted into the current wordlist at the :, but
marked as unfindable. ; marks it as findable.

REVEAL: The word is inserted into the current wordlist at the ;.

With the REVEAL approach, it is necessary to store the latest word
somewhere (in LAST), so that REVEAL then knows which word to insert
into the current wordlist. It is also necessary to remember where
:NONAME was used, because then REVEAL at the ";" does nothing. This
leads to LATEST producing the nt of named words and 0 for unnamed
words, irrespective of the current wordlist.

With the SMUDGE approach, it is natural that the LATEST word is
accessed through the current wordlist. Not sure how ";" knows what to
do on a :NONAME.

Anyway, if we continue to support both approaches (and I don't expect
a consensus on giving up one of them), a loose LATEST would be a
natural consequence. Of course, we may still decide on a tighter one.

[Krishna Myneni]

On Wed, 04 Sep 2019 10:19:06 +0300, Ruvim wrote:

> On 2019-09-04 02:07, Krishna Myneni wrote:
>> On Wed, 04 Sep 2019 02:01:45 +0300, Ruvim wrote:
>>
>> ....
>>> Hence we have:
>>>
>>> XXX ( -- nt ) or ( -- nt|0 )
>>> ~~~ return nt for the last definition
>>>
>>>
>> ....
>>> Should it take into account the nameless definitions? (i.e. may a
>>> nameless definition be the last definition) If yes, what to return if
>>> the last definition is nameless?
>>> NB: in some systems it can have nt nevertheless.
>>>
>>>
>> Logically, no, a nameless definition cannot have an "nt", since, per
>> the Forth-2012 standard, the "nt" is defined as a token to a named
>> word.
>
>
> 1. The Standard does not prohibit to create "nt" for a definition that
> is created via ':NONAME'.
>

To be clear, returning an "nt" of NULL for a :NONAME definition does not
invalidate the interpretation of "nt" as a token for a named word.
Earlier I have asked for clarification on the matter of what "nt" refers
to, and, Anton Ertl has replied with what I considered an unambiguous
response that "nt" distinguishes a named-word:

https://groups.google.com/d/msg/comp.lang.forth/gIiF2WaFVDw/Aa_cMSs9AwAJ

The Forth-2012 document also uses "name token" for "nt" which I consider
to be misleading. I have put in a proposal to revise the language in the
standard,

http://forth-standard.org/standard/tools#contribution-109

> E.g. Gforth creates "nt" with zero-length name for such definition, and
> this behavior does not violate the Standard.
>

If a word with zero-length name is to be considered a special case of a
named word, then this language needs to be added to the standard. As it
stands:

----

15.3.1 Data types
A name token is a single-cell value that identifies a named word.

----

However, appending a sentence like "An unnamed word is a special case of
a named word with a zero length name." would just make the phrase "name
token" meaningless, in my opinion.

...

> 2. Your reasoning is not relevant to the question. Since "last
> definition" term can be defined in such a way that a nameless definition
> can be the last definition too. And the options for XXX in this case are
> the following:
> — it should return 0 — it should return nt-null — it may return nt
> (if the system supports it) or 0.
> — it may return nt (if the system supports it) or nt-null.
>

This is addressed above. I was not clear about this earlier.

>
>> If we want to call it a "word token" to encompass both named and
>> unnamed words, that's fine.
>
> If a name is zero-length, is it a named or an unnamed word?

In my view, if a word with zero-length name is not considered an unnamed
word, it makes the distinction meaningless.

Krishna Myneni

[JennyB]

On Tuesday, 3 September 2019 08:19:17 UTC+1, Anton Ertl wrote:

> While I expect that there are Forth systems where an xt -> nt
> conversion is not possible, I have problems following your
> explanation. Of course a Forth compiler may compile, say, + into an
> add instruction that has no relation to the xt, there still has to be
> an xt for +, and you can get it with "' +". Whether you can get the
> nt from this xt is a different question.
>

Gforth is one such system, I think. A default word and an interpret/compile word may return the same xt, so which nt should that xt return?

[Ruvim]

On 2019-09-04 09:52, Anton Ertl wrote:
> Ruvim <ruvim...@gmail.com> writes:
>> Hence we have:
>>
>> XXX ( -- nt ) or ( -- nt|0 )
>> ~~~ return nt for the last definition
>>
>>
>> If somebody still want to design a specification for this word, the
>> following question should be definite:
>>
>>
>> In what domain the definition should be the last one?
>> - the last defined in the current wordlist?
>> - the last defined from the Forth system or current thread start
>> (the most recent definition)?
>
> fig-Forth's LATEST produces the former. Gforth's LATEST produces the
> latter. Nobody has complained about that, so one option is to leave
> it open (e.g., by making it an ambiguous condition).
>
> If we want to avoid such looseness, I obviously think that the latter
> is preferable.

It seems the former is simpler for specification — no need to mind the
cases of the auxiliary or internal definitions (like local variables,
quotations, etc).

>
>> Should it take into account the nameless definitions?
>> (i.e. may a nameless definition be the last definition)
>> If yes, what to return if the last definition is nameless?
>> NB: in some systems it can have nt nevertheless.
>
> In Gforth LATEST returns 0 if the last definition is nameless, and the
> very recent LATESTNT returns the nt of that definition.
>
> In SwiftForth LAST @ returns 0 if the last definition is nameless.
>
> In VFX LATEST returns the address of the control field of the last
> named definition (note that thus address does not serve as nt; you
> have to write LATEST CTRL>NFA to get the nt).
>
> Interestingly, in VFX even LATEST-XT returns the xt of the last named
> word (even if there is a later :NONAME), while in Gforth LATESTXT
> returns the xt of the latest word whether named or not.
>
>> Should it take into account the current definition (if it exists)?
>> (i.e. may the current definition be the last definition)
>> NB: it can be nameless.
>> NB: for some systems, even nt can be obtained for the current
>> definition, NAME>* words can return incorrect (or not final)
>> result while compilation of this definition is not ended.
>
> That question is unclear to me. What, if not the last definition, do
> you mean with "current definition".

"last definition" is not well defined term, and in general case it can
be defined in such a way that either includes or excludes the current
definition.

| current definition:
| The definition whose compilation has been started but not yet ended.


I have just realized that with quotations there more than one definition
can be the current definition. And due to undefined limitation for
nesting, the max number of the current definitions is undefined too.

E.g.:

: foo
[:
( in this place the both 'foo' and this quotation
are started and not ended )
;]
( here the most recent /completed/ definition is the quotation,
but the current definition is 'foo' )
;

Perhaps it is better to separate the current definition and the last
definition.


Also, when Quotations will be included into the standard, the "current
definition" term should be perhaps updated.

In SP-Forth the corresponding variables are user-variables (due to
multi-threading text-interpreter), and therefore the initial value after
start is 0 in each thread independently.


Wrt nt-null it is just an allusion to RECTYPE-NULL
Why don't to use a special value in place of 0 in every case?

[Alex McDonald]

On 04-Sep-19 08:19, Ruvim wrote:
> it should return nt-null

I will fight to my dying breath (ok, a bit of hyperbole there) anyone
and any proposal that introduces types of nulls like NT-NULL or
RECTYPE-NULL.

These are (a) not NULL (b) disjoint from each other (c) pointless.

Use zero and be done with it. Then we can have

0 constant NULL

and get on with programming without having to concern ourselves with 50
shades of nulls.

--
Alex

[Ruvim]

On 2019-09-04 13:33, Alex McDonald wrote:
> On 04-Sep-19 08:19, Ruvim wrote:
>> it should return nt-null
>
> I will fight to my dying breath (ok, a bit of hyperbole there) anyone
> and any proposal that introduces types of nulls like NT-NULL or
> RECTYPE-NULL.

I totally agree.

I just tried to show on this example that consistency is very important
and RECTYPE-NULL approach is a bad design choice.

> These are (a) not NULL (b) disjoint from each other (c) pointless.
>
> Use zero and be done with it. Then we can have
>
> 0 constant NULL
>
> and get on with programming without having to concern ourselves with 50
> shades of nulls.

Agree.

[Anton Ertl]

Ruvim <ruvim...@gmail.com> writes:
>On 2019-09-04 09:52, Anton Ertl wrote:
>> Ruvim <ruvim...@gmail.com> writes:
>>> Hence we have:
>>>
>>> XXX ( -- nt ) or ( -- nt|0 )
>>> ~~~ return nt for the last definition
>>>
>>>
>>> If somebody still want to design a specification for this word, the
>>> following question should be definite:
>>>
>>>
>>> In what domain the definition should be the last one?
>>> - the last defined in the current wordlist?
>>> - the last defined from the Forth system or current thread start
>>> (the most recent definition)?
>>
>> fig-Forth's LATEST produces the former. Gforth's LATEST produces the
>> latter. Nobody has complained about that, so one option is to leave
>> it open (e.g., by making it an ambiguous condition).
>>
>> If we want to avoid such looseness, I obviously think that the latter
>> is preferable.
>
>It seems the former is simpler for specification — no need to mind the
>cases of the auxiliary or internal definitions (like local variables,
>quotations, etc).

For Gforth that would mean that XXX would exist in addition to LATEST
and LATESTNT. These are necessary because, e.g., MAKE-LATEST does not
change the last word defined in the current wordlist, and therefore
the Gforth uses LATEST and LATESTNT internally. So for Gforth XXX
would just be a needless (although small) complication.

>>> Should it take into account the current definition (if it exists)?
>>> (i.e. may the current definition be the last definition)
>>> NB: it can be nameless.
>>> NB: for some systems, even nt can be obtained for the current
>>> definition, NAME>* words can return incorrect (or not final)
>>> result while compilation of this definition is not ended.
>>
>> That question is unclear to me. What, if not the last definition, do
>> you mean with "current definition".
>
>"last definition" is not well defined term, and in general case it can
>be defined in such a way that either includes or excludes the current
>definition.
>
>| current definition:
>| The definition whose compilation has been started but not yet ended.

IMMEDIATE refers to the "most recent definition". Using the following
as a test:

: foo ." foo" ;
: bar [ immediate ] ." bar" ;
: boing foo bar ;

Swiftforth, VFX, and Gforth print "bar" (i.e., BAR is immediate),
iForth prints "foo" (i.e., FOO is immediate).

>I have just realized that with quotations there more than one definition
>can be the current definition. And due to undefined limitation for
>nesting, the max number of the current definitions is undefined too.

RECURSE and DOES> refer to "the current definition", and are addressed
in the quotation proposal. The "current definition" is also addressed
there:

[:
[...]
suspends compiling to the current definition, starts a new nested
definition with execution token xt, and compilation continues with
this nested definition. [...]

;]
[...]
Ends the current nested definition, and resumes compilation to the
previous (containing) current definition. It appends the following
run-time to the (containing) current definition:
[...]

>Perhaps it is better to separate the current definition and the last
>definition.

The "most recent" definition of IMMEDIATE seems to be more relevant
for LATEST than the current definition, but as we see above, it also
has its perils.

>>> What to return if the last definition is absent? Should it return the
>>> predefined nt-null (that is not null) in such case, or just 0?
>>
>> In Gforth, if you call LATEST before defining a word, it returns the
>> last word defined by the system before the image was saved. The same
>> seems to be the case for VFX.
>
>In SP-Forth the corresponding variables are user-variables (due to
>multi-threading text-interpreter), and therefore the initial value after
>start is 0 in each thread independently.

You can also specify that the value of LATEST returned at the start of
a session is implementation-defined or somesuch.

>Wrt nt-null it is just an allusion to RECTYPE-NULL
>Why don't to use a special value in place of 0 in every case?

Matthias Trute was asked the same question about RECTYPE-NULL, and his
answer was a demonstration that it results in less code. I guess if
you propose NT-NULL, you will get asked the same question, unless you
already demonstrate less code or some other benefit in the proposal.

[Anton Ertl]

In current development Gforth, every xt has a primary nt (in Gforth
0.7 unnamed xts were not necessarily associated with an nt) that you
get with XT>NAME (and, for named words, also with >NAME).

Which one that is depends on how the word was constructed. Here are
three words with identical interpretation and compilation semantics:

:noname ." interpreting" ;
:noname ." compiling" ;
interpret/compile: dual1

: dual2
." interpreting" ;
compsem:
." compiling" ;

: dual3
." compiling" ;
intsem:
." interpreting" ;

' dual1 >name . \ 0 ok
' dual2 >name . \ 139674460044680 ok
' dual2 >name name>string type \ dual2 ok
' dual3 >name . \ 0 ok

comp' dual3 \ ok 2
>name name>string type \ execute ok 1
>name name>string type \ dual3 ok

So the primary nt of the interpretation semantics of DUAL1 is that of
the first :NONAME definition (and because it is a :NONAME definition,
you get 0 out of >NAME); the primary nt of the interpretation
semantics of DUAL2 is the nt of DUAL2; the primary nt of the
interpretation semantics of dual3 is that of the nameless definition
started by INTSEM:, so again >NAME produces 0.

[dxforth]

On Wednesday, 4 September 2019 22:56:16 UTC+10, Anton Ertl wrote:
> Ruvim <ruvim...@gmail.com> writes:

> > ...

> >"last definition" is not well defined term, and in general case it can
> >be defined in such a way that either includes or excludes the current
> >definition.
> >
> >| current definition:
> >| The definition whose compilation has been started but not yet ended.
>
> IMMEDIATE refers to the "most recent definition".

No mention of 'current' or 'compiling' at all.

> Using the following
> as a test:
>
> : foo ." foo" ;
> : bar [ immediate ] ." bar" ;
> : boing foo bar ;
>
> Swiftforth, VFX, and Gforth print "bar" (i.e., BAR is immediate),
> iForth prints "foo" (i.e., FOO is immediate).

So the spec isn't idiot-proof - does it need to be?

[JennyB]

That seems logical. Do you still have COMPILE-ONLY as a variant of INTSEM: ?

It mostly conforms with the expectation that each definition has a unique xt, and any special behaviour, such as being IMMEDIATE is added to it later (but before the next definition).

The case I had in mind which breaks this was:

: foo ." interpreting" ;
' foo
:noname ." compiling" ;
interpret/compile: dual4

' dual4 >name name>string type \ foo ok
' dual4 >name name>compile \ ok 2
>name >string type \ compile, ok 1
>name >string type \ foo ok

comp' dual4 \ ok 2
>name >string type \ execute
>name . \ 0

I've no objection to synonyms sharing xts, because I expect a synonym to be something like a file-system shortcut.

SYNONYM B A
...
SYNONYM C B
...
' C >name name>string type \ A ok

[Alex McDonald]

: gen1 : immediate postpone ; ;
gen1 bar
: gen2 : postpone ; immediate ;
gen2 foo

What should I expect here? I don't have a copy of iFprth, but from
Anton's test I suspect

GEN1 is marked immediate by its own execution
BAR is not immediate
GEN2 is not immediate
FOO is marked immediate by GEN2's execution

--
Alex

[Gerry Jackson]

On 04/09/2019 07:52, Anton Ertl wrote:
> Ruvim <ruvim...@gmail.com> writes:
>

> That's the case in Gforth, but the previous LATEST etc. is restored
> when the locals or quotation definition ends:
>
> : foo \ compiled
> [ latest hex. ] \ $7F610CF9E888 compiled
> {: a :} [ latest hex. ] \ $7F610CF9E888 compiled
> [: [ latest hex. ] ;] \ $0 compiled
> [ latest hex. ] ; \ $7F610CF9E888 ok
>
>> What to return if the last definition is absent? Should it return the
>> predefined nt-null (that is not null) in such case, or just 0?
>
> In Gforth, if you call LATEST before defining a word, it returns the
> last word defined by the system before the image was saved. The same
> seems to be the case for VFX.
>
>> May the returned nt be unreachable via TRAVERSE-WORDLIST?
>
> In Gforth, it certainly is before the word is REVEALed. E.g., in the
> definition of FOO above, FOO is only REVEALed at ";", but LATEST
> returns the nt earlier.

What happens to LATEST after FORGET or use of a MARKER? What should
happen? Set to zero possibly. MARKER could record the value of LATEST
for restoring later but that would be difficult if not impossible for
FORGET.

--
Gerry

[JennyB]

On Wednesday, 4 September 2019 09:49:01 UTC+1, Anton Ertl wrote:
> Ruvim <ruvim...@gmail.com> writes:
> >In what domain the definition should be the last one?
> > - the last defined in the current wordlist?
> > - the last defined from the Forth system or current thread start
> > (the most recent definition)?
>
> This question is related to how to deal with words between : and ;.
> There are two common options:
>
> SMUDGE: The word is inserted into the current wordlist at the :, but
> marked as unfindable. ; marks it as findable.
>
> REVEAL: The word is inserted into the current wordlist at the ;.
>
> With the REVEAL approach, it is necessary to store the latest word
> somewhere (in LAST), so that REVEAL then knows which word to insert
> into the current wordlist. It is also necessary to remember where
> :NONAME was used, because then REVEAL at the ";" does nothing. This
> leads to LATEST producing the nt of named words and 0 for unnamed
> words, irrespective of the current wordlist.
>
> With the SMUDGE approach, it is natural that the LATEST word is
> accessed through the current wordlist. Not sure how ";" knows what to
> do on a :NONAME.
>
> Anyway, if we continue to support both approaches (and I don't expect
> a consensus on giving up one of them), a loose LATEST would be a
> natural consequence. Of course, we may still decide on a tighter one.
>

At present, the Standard covers the difference with this ambiguous condition:

An ambiguous condition exists if a program changes the compilation word
list during the compilation of a definition or before modification of the
behavior of the most recently compiled definition with ;CODE, DOES>, or
IMMEDIATE.

If we can live with that, then LATEST might as well just return the most
recent nt on the CURRENT wordlist, because that is guaranteed not to change.

In the REVEAL: scheme however, the new header of a colon definition is not
yet linked to any wordlist, so the nt must be stored elsewhere for LATEST.
Either way, the effect is the same, the nt returned by LATEST remains valid
until another definition is started.

I have, in the past, violated the condition with the words:

wid CREATION \ CREATE a new definition on /wordlist/
wid DEF: \ A new colon definition on /wordlist/

On a REVEAL: Forth CREATION will work, and DOES> and IMMEDIATE and any other
word that uses LATEST will also work as expected, because LATEST doesn't
care what is the CURRENT wordlist.

:DEF, however, will not. OR rather IMMEDIATE will mark it as IMMEDIATE, but REVEAL will link it to the wrong wordlist. That's no big problem: I could
just as easily have defined:

DEF: ( xt wid -- ) CREATION , DOES> @ EXECUTE ;

So long as LATEST works as above, the ambiguous condition can be reduced to:

An ambiguous condition exists the compilation word list differs between
the start of compiling a colon definition and its completion.

And even that can be removed if a REVEAL: Forth passes the wid as part of
colon-sys. :NONAME might pass 0 instead, so that REVEAL would know not to link it to a wordlist.

[dxforth]

https://www.youtube.com/watch?v=xCc-RWIp7XU

[Anton Ertl]

Alex McDonald <al...@rivadpm.com> writes:
>: gen1 : immediate postpone ; ;
>gen1 bar
>: gen2 : postpone ; immediate ;
>gen2 foo
>
>What should I expect here? I don't have a copy of iFprth, but from
>Anton's test I suspect
>
>GEN1 is marked immediate by its own execution
>BAR is not immediate
>GEN2 is not immediate
>FOO is marked immediate by GEN2's execution

Yes, iForth seems to behave this way.

[Anton Ertl]

Gerry Jackson <do-no...@swldwa.uk> writes:
>What happens to LATEST after FORGET or use of a MARKER? What should
>happen? Set to zero possibly. MARKER could record the value of LATEST
>for restoring later but that would be difficult if not impossible for
>FORGET.

Gforth does not have FORGET. A marker could restore latest (and IIRC
this has been discussed many years ago), but in Gforth it does not,
yet. So LATEST is just invalid after performing a marker.

[Anton Ertl]

Yes, this caters for SMUDGE systems putting the word in the wordlist
current at : and REVEAL systems putting the word in the wordlist
current at ;. However, Gforth is a REVEAL system that puts the word
in the wordlist current at :.

>If we can live with that, then LATEST might as well just return the most
>recent nt on the CURRENT wordlist, because that is guaranteed not to change.

Yes, a standard program is not allowed to SET-CURRENT between : and ;.

However, what you propose would mean that

: foo ;
: bar [ latest name>string type ] ;

would print "bar" in a SMUDGE system and print "foo" in a REVEAL
system. And that would be pretty perverse, because REVEAL systems
have a LATEST that remembers BAR, in order for REVEAL to work.

>In the REVEAL: scheme however, the new header of a colon definition is not
>yet linked to any wordlist, so the nt must be stored elsewhere for LATEST.
>Either way, the effect is the same, the nt returned by LATEST remains valid
>until another definition is started.

Apart from LATEST, the following is a standard program:

wordlist constant wl
: foo ;
wl set-current
latest name>string type

This is a program where you would see the difference between LATEST
accessing the current wordlist (fig-Forth), and LATEST being stored
separately (Gforth).

Could be addressed by making LATEST ambiguous if the current wordlist
is changed between the most recent definition and LATEST.

[Anton Ertl]

In development Gforth, all words have interpretation semantics. We
still have COMPILE-ONLY, but it does not change the interpretation
semantics. COMPILE-ONLY just means that in some cases you get a
warning when accessing the interpretation semantics.

>It mostly conforms with the expectation that each definition has a unique xt, and any special behaviour, such as being IMMEDIATE is added to it later (but before the next definition).
>
>The case I had in mind which breaks this was:
>
> : foo ." interpreting" ;
> ' foo
> :noname ." compiling" ;
> interpret/compile: dual4
>
> ' dual4 >name name>string type \ foo ok
> ' dual4 >name name>compile \ ok 2
> >name >string type \ compile, ok 1
> >name >string type \ foo ok

Note that "' DUAL4" produces the xt of FOO, and when you use >NAME on
that, you get the nt of FOO, not of DUAL4. And when you then apply
NAME>COMPILE on it, you get the compilation semantics of FOO, not of
DUAL4.

Anyway, concerning whether each definition has a unique xt: Each named
word has a unique nt, but what you get by ticking is not such a unique
xt; in the case of an INTERPRET/COMPILE: word, you get the xt of the
interpret part.

In development Gforth, one goal was to unify nt and xt as far as
possible, leading to the following goals:

|* For many words, the nt and the xt representing the interpretation
| semantics are the same address.
|
|* You can pass an xt to a word that expects an nt, and you will get a
| plausible result.
|
|* You can pass an nt to a word that expects an xt, and you will get a
| plausible result.

The latter works by letting words created by SYNONYM and
INTERPRET/COMPILE: have dodefer in their code field, and the xt or nt
of the interpretation semantics in the parameter field. So EXECUTE
and COMPILE, behave as if they were passed the xt of the
interpretation semantics. However, >BODY does not (it's a simple
field access word), so the following does not satisfy the third goal:

create foo 5 ,
synonym bar foo
' bar find-name >body @ . \ 5 ok
s" bar" find-name >body @ . \ 139663534864416 ok

[dxforth]

Don't have iForth. As to legality I would base it on 'common
practice' of IMMEDIATE which after all is what ANS sought to define.
Classically IMMEDIATE has been 'dumb' with no special attributes.

Case 1: illegal - it's not 'common practice' to apply IMMEDIATE
while a definition is being compiled.

Case 2: legal - doesn't do anything contrary to 'common practice'.
No attempt to exploit or fool the compiler.

[Alex McDonald]

That's not what's happening. Nothing happens to change its immediacy
during its compilation. During its /execution/, IMMEDIATE acts on GEN1,
not BAR.

>
> Case 2: legal - doesn't do anything contrary to 'common practice'.
> No attempt to exploit or fool the compiler.
>

The difference is where the IMMEDIATE is placed and both are legal; the
compiler isn't being "fooled". The standard says

IMMEDIATE
( -- )
Make the /most recent definition/ an immediate word.

Which of GEN1 or BAR is the /most recent definition/?

--
Alex

[Ruvim]

I left some comments there.

My conclusion is that "named word" literally means "named named Forth
definition", since "word" is a named Forth definition.
Therefore, "named word" is a pleonasm (a kind of tautology).

If a definition has a name, such definition may be (and often is)
called "word".

If a definition has no name (nameless definition), this definition can
be called "unnamed word" (or some such) informally or as a slang, but
not in a normative text.

So, the "named word" expression isn't a well style (since all words have
names a priori), that occurs once in Forth-94 standard though. Perhaps
we should rewording such usage and update some definitions in the
current standard.



[...]

[Alex McDonald]

: bar 10 ;
' bar $.
synonym foo bar

$. prints the address of the word. The word's name representing the
address is both BAR and FOO. The address is also an execution token,
because we can pass it to EXECUTE. The definition of BAR is to put the
constant 10 on the stack when it is executed.

>
> If a definition has no name (nameless definition), this definition can
> be called "unnamed word" (or some such) informally or as a slang, but
> not in a normative text.

:noname 10 ; $.

$. prints the address of the word. The word doesn't have a name. The
address is also an execution token, because we can pass it to EXECUTE.
The definition of the unnamed word is to put the constant 10 on the
stack when it is executed.

What's hard about this?

>
> So, the "named word" expression isn't a well style (since all words have
> names a priori), that occurs once in Forth-94 standard though. Perhaps
> we should rewording such usage and update some definitions in the
> current standard.
>

This is a discussion with little if any merit. Words have unique
addresses, and they can have no to many names that are easily remembered
handles for those addresses. Everything else is hair splitting.

--
Alex

[JennyB]

On Thursday, 5 September 2019 10:28:50 UTC+1, Alex McDonald wrote:

> >> : gen1 : immediate postpone ; ;
> >> gen1 bar
> >> : gen2 : postpone ; immediate ;
> >> gen2 foo
> >>
> >> What should I expect here? I don't have a copy of iFprth, but from
> >> Anton's test I suspect
> >>
> >> GEN1 is marked immediate by its own execution
> >> BAR is not immediate
> >> GEN2 is not immediate
> >> FOO is marked immediate by GEN2's execution

> The difference is where the IMMEDIATE is placed and both are legal; the
> compiler isn't being "fooled". The standard says
>
> IMMEDIATE
> ( -- )
> Make the /most recent definition/ an immediate word.
>
> Which of GEN1 or BAR is the /most recent definition/?
>

I would say that the most recent definition is the most recent header that
has been created - in this case BAR.

If the intention is to make GEN1 immediate then there is no good reason to
place immediate where it is. A clearer definition (which should work with
all Forths) would be:

: GEN1 immediate : postpone ; ;
\ make the most recent definition immediate
\ then create a non-immediate do-nothing definition

Though GEN1 and GEN2 probably should be functionally identical I think the
latter is the better style, to avoid confusion with:

: GEN3 : postpone immediate postpone ; ;
\ create a definition that makes the most recent definition immediate

[Alex McDonald]

GEN3 won't work as you intend; it will compile an IMMEDIATE into
whatever invokes it.


--
Alex

[Ruvim]

On 2019-09-05 22:01, JennyB wrote:
> On Thursday, 5 September 2019 10:28:50 UTC+1, Alex McDonald wrote:
>
>>>> : gen1 : immediate postpone ; ;
>>>> gen1 bar
>>>> : gen2 : postpone ; immediate ;
>>>> gen2 foo
>>>>
>>>> What should I expect here? I don't have a copy of iFprth, but from
>>>> Anton's test I suspect
>>>>
>>>> GEN1 is marked immediate by its own execution
>>>> BAR is not immediate
>>>> GEN2 is not immediate
>>>> FOO is marked immediate by GEN2's execution
>
>> The difference is where the IMMEDIATE is placed and both are legal; the
>> compiler isn't being "fooled". The standard says
>>
>> IMMEDIATE
>> ( -- )
>> Make the /most recent definition/ an immediate word.
>>
>> Which of GEN1 or BAR is the /most recent definition/?
>>
> I would say that the most recent definition is the most recent header
> that has been created - in this case BAR.

What makes you think that the header for BAR has been created before
IMMEDIATE is performed? The Standard doesn't specify when to create a
header. It may be created even on ';'.

I think, if we talk about a definition as the whole — it should be
completed and ready to use (i.e. compilation of the definition should be
ended). From this point of view, "most recent definition" should be
interpreted as "most recent /completed/ definition".

In any case, at the moment an ambiguous condition exists a posteriori if
IMMEDIATE is performed when the current definition is not absent.


--
Ruvim

[Krishna Myneni]

On Thu, 05 Sep 2019 15:23:44 +0300, Ruvim wrote:

> On 2019-09-04 13:08, Krishna Myneni wrote:
>> On Wed, 04 Sep 2019 10:19:06 +0300, Ruvim wrote:
>>
>>> On 2019-09-04 02:07, Krishna Myneni wrote:

...

>>
>> http://forth-standard.org/standard/tools#contribution-109
>
> I left some comments there.
>

Yes, I replied this morning. Good points.

...

> If a definition has a name, such definition may be (and often is)
> called "word".
>
> If a definition has no name (nameless definition), this definition can
> be called "unnamed word" (or some such) informally or as a slang, but
> not in a normative text.

"Nameless definition" works.

KM

[Krishna Myneni]

On Thu, 05 Sep 2019 14:07:25 +0100, Alex McDonald wrote:

...

> This is a discussion with little if any merit. Words have unique
> addresses, and they can have no to many names that are easily remembered
> handles for those addresses. Everything else is hair splitting.

I disagree that it is hair splitting. Nor is it "bikeshedding". There is
confusion about the meaning of "nt" as defined in the standard. Now, the
talk about returning "nt"s for definitions which are created with :NONAME
introduces a logical inconsistency with the standard, which apparently
people in this discussion would prefer to ignore. Ignoring this is what
is wasting everyone's time, including mine.

If the preferred approach is to just leave open-ended the interpretation
of "nt", and disregard the language in the standard, then that could be a
valid strategy to say that "nt" is a to-be established specification at a
later date. But this should be stated explicitly. Otherwise, it makes
little sense to talk about words which return "nt"s when no one can offer
a consistent and precise definition of "nt". If you would care to offer
one, please do so.


Krishna

[dxforth]

No. You are attempting to use the words of the standard to
justify a practice that wasn't common. That's being cunning
and I'm not fooled by such tricks.

If you believe the new practice has value then you should be
able to justify it on its own merits as a new a proposal.

>
> Which of GEN1 or BAR is the /most recent definition/?

Ambiguous - it was never common practice to do that.

>
> --
> Alex

[Ruvim]

On 2019-09-04 15:06, Anton Ertl wrote:
> Ruvim <ruvim...@gmail.com> writes:

[...]

>> | current definition:
>> | The definition whose compilation has been started but not yet ended.

>> I have just realized that with quotations there more than one definition
>> can be the current definition. And due to undefined limitation for
>> nesting, the max number of the current definitions is undefined too.
>
> RECURSE and DOES> refer to "the current definition", and are addressed
> in the quotation proposal. The "current definition" is also addressed
> there:
>
> [:
> [...]
> suspends compiling to the current definition, starts a new nested
> definition with execution token xt, and compilation continues with
> this nested definition. [...]
>
> ;]
> [...]
> Ends the current nested definition, and resumes compilation to the
> previous (containing) current definition. It appends the following
> run-time to the (containing) current definition:
> [...]

Yes, they are addressed [1]. So, with Quotations we have two types of
current definitions: suspended and not suspended (and we don't know what
"to suspend" means); but the main issue: now more than one Forth
definition can be the current definition in the same time — according
the the term definition. And because of this issue you had to address
RECURSE and DOES> and invent the new notion of suspending (that is
different in "3.4.5").


Another approach is to just update the "current definition" term to
guarantee that not more than one definition can be the current definition.

E.g.:
current definition: the definition whose compilation has been started
*most recently* among those whose compilation hasn't been ended.

After that the specifications for '[:' and ';]' words can be expressed
similar to ':NONAME' and ';' as the following (holding the original style):


[: bracket-colon
Compilation: ( C: -- quotation-sys colon-sys )
*Start compilation of the new definition*, producing (quotation-sys
colon-sys). Append the initiation semantics given below to the current
definition.
Initiation: ( i*x -- i*x ) ( R: -- nest-sys )
Save implementation-dependent information nest-sys about the calling
definition. The stack effects i*x represent arguments to the definition.

;] semi-bracket
Compilation: ( C: quotation-sys colon-sys -- )
Append the run-time 1 semantics below to the current definition. End
compilation of the current definition, consuming (quotation-sys
colon-sys). Append the run-time 2 semantics below to the current definition.
Run-time 1: ( -- ) ( R: nest-sys -- )
Return to the calling definition specified by nest-sys.
Run-time 2: ( -- xt )
Place xt on the stack. xt is the execution token for the definition that
was ended on performing the compilation semantics above.


And now we don't need to address RECURSE or DOES>

But in any case we also need to update "3.4.5 Compilation" wrt "A
program shall not attempt to nest compilation of definitions".


[1] The proposal itself, for reference:
http://www.forth200x.org/quotations-v3.txt

--
Ruvim

[A. K.]

Am Freitag, 6. September 2019 00:31:08 UTC+2 schrieb Krishna Myneni:
> On Thu, 05 Sep 2019 14:07:25 +0100, Alex McDonald wrote:
>
> ...
> > This is a discussion with little if any merit. Words have unique
> > addresses, and they can have no to many names that are easily remembered
> > handles for those addresses. Everything else is hair splitting.
>
> I disagree that it is hair splitting. Nor is it "bikeshedding". There is
> confusion about the meaning of "nt" as defined in the standard. Now, the
> talk about returning "nt"s for definitions which are created with :NONAME
> introduces a logical inconsistency with the standard, which apparently
> people in this discussion would prefer to ignore. Ignoring this is what
> is wasting everyone's time, including mine.

NTs appear only in the optional Programmung Tools Wordset.

Now they are enthusiastically driven into Core without necessity.

[Anton Ertl]

Ruvim <ruvim...@gmail.com> writes:
>Another approach is to just update the "current definition" term to
>guarantee that not more than one definition can be the current definition.
>
>E.g.:
> current definition: the definition whose compilation has been started
>*most recently* among those whose compilation hasn't been ended.

Sounds good.

>After that the specifications for '[:' and ';]' words can be expressed
>similar to ':NONAME' and ';' as the following (holding the original style):
>
>
>[: bracket-colon
> Compilation: ( C: -- quotation-sys colon-sys )
>*Start compilation of the new definition*, producing (quotation-sys
>colon-sys). Append the initiation semantics given below to the current
>definition.
> Initiation: ( i*x -- i*x ) ( R: -- nest-sys )
>Save implementation-dependent information nest-sys about the calling
>definition. The stack effects i*x represent arguments to the definition.
>
>;] semi-bracket
> Compilation: ( C: quotation-sys colon-sys -- )
>Append the run-time 1 semantics below to the current definition. End
>compilation of the current definition, consuming (quotation-sys
>colon-sys). Append the run-time 2 semantics below to the current definition.
> Run-time 1: ( -- ) ( R: nest-sys -- )
>Return to the calling definition specified by nest-sys.
> Run-time 2: ( -- xt )
>Place xt on the stack. xt is the execution token for the definition that
>was ended on performing the compilation semantics above.

This fails to capture is that you can use [: ... ;] inside a colon
definition, but no other defining word; however, 3.4.5 addresses that.

>And now we don't need to address RECURSE or DOES>

Yes, that comes from the adjustment of the definition of "current
definition".

>But in any case we also need to update "3.4.5 Compilation" wrt "A
>program shall not attempt to nest compilation of definitions".

This section explicitly mentions "any defining word, :NONAME", but not
[:, so from that point of view that is ok. Explicitly mentioning
[:...;] might make things clearer, though. OTOH, the explicit mention
of [ ... ] has led to misunderstandings.

[Alex McDonald]

No-one is trying to trick you or be cunning.

>
> If you believe the new practice has value then you should be
> able to justify it on its own merits as a new a proposal.

What new practice? I think you're misunderstanding what happens and when.

>
>>
>> Which of GEN1 or BAR is the /most recent definition/?
>
> Ambiguous - it was never common practice to do that.

It has been common practise to apply IMMEDIATE to words since the dawn
of Forth. But IMMEDIATE stands alone and needs some context to act; what
we're discussing is how systems should identify the most recent
definition, to remove an ambiguity that impinges on
LASTEST/LAST/LATESTNT/whatever it's going to be called. Is there a most
recent definition "name"

: name ( here ) ; ( or only here )

Even if you don't think words like LASTEST/LAST/LATESTNT/whatever should
be standardized, something like it is used in defining IMMEDIATE, and
this has led to this difference in implementation.

--
Alex

[dxforth]

On Friday, 6 September 2019 18:18:58 UTC+10, Alex McDonald wrote:
> On 06-Sep-19 01:45, dxforth wrote:

> ...

> > If you believe the new practice has value then you should be
> > able to justify it on its own merits as a new a proposal.
>
> What new practice?

Executing IMMEDIATE in the middle of compiling a colon definition.

> I think you're misunderstanding what happens and when.

I think you're misunderstanding what ANS was all about.

> >> Which of GEN1 or BAR is the /most recent definition/?
> >
> > Ambiguous - it was never common practice to do that.
>
> It has been common practise to apply IMMEDIATE to words since the dawn
> of Forth.

Then presumably you know what the common practice usage is. Perhaps you
want to make the ANS spec idiot-proof? In that case I would suggest only
a hermit would need it since how to implement or use IMMEDIATE is easily
found by looking or asking. It's not as if these things had never been
done before.

[JennyB]

I think you'll find it does:

GEN3 Foo

produces the definition:

: Foo immediate ;

which is a bit silly, but less so if GEN3 compiles something else in Foo as well.

[Alex McDonald]

On 06-Sep-19 11:25, dxforth wrote:
> On Friday, 6 September 2019 18:18:58 UTC+10, Alex McDonald wrote:
>> On 06-Sep-19 01:45, dxforth wrote:
>> ...
>>> If you believe the new practice has value then you should be
>>> able to justify it on its own merits as a new a proposal.
>>
>> What new practice?
>
> Executing IMMEDIATE in the middle of compiling a colon definition.

What do you mean by "the middle of a definition"?

create bar immediate

I can't see a middle.

: foo create , immediate does> @ ;

Where is the "middle of the definition" in FOO? How do I make a CREATEd
word immediate, or do I take your word for it and not bother because I'm
executing IMMEDIATE in the "middle of a definition"?

>
>> I think you're misunderstanding what happens and when.
>
> I think you're misunderstanding what ANS was all about.
>
>>>> Which of GEN1 or BAR is the /most recent definition/?
>>>
>>> Ambiguous - it was never common practice to do that.
>>
>> It has been common practise to apply IMMEDIATE to words since the dawn
>> of Forth.
>
> Then presumably you know what the common practice usage is. Perhaps you
> want to make the ANS spec idiot-proof? In that case I would suggest only
> a hermit would need it since how to implement or use IMMEDIATE is easily
> found by looking or asking. It's not as if these things had never been
> done before.
>

So why does iForth do it differently from others? Is Marcel Hendrix an
idiot hermit?

--
Alex

[Alex McDonald]

Oh, I see, you were pointing out the potential confusion with

: gen2 : immediate postpone ; ;

OK, but the issue still stands; dxforth is arguing that (another variety)

: gen4 : immediate ;
gen4 bar 10 ;

isn't idiomatic Forth or has no existing practice. How we're to
satisfactorily generate IMMEDIATE words is beyond me if that's the case.

--
Alex

[foxaudio...@gmail.com]

On Wednesday, September 4, 2019 at 11:59:46 AM UTC-4, dxforth wrote:

> So the spec isn't idiot-proof - does it need to be?

It would be in conflict with Murphy's law of Engineering.

"Nothing can be made idiot-proof. Idiots have too much ingenuity." :-)

[Alex McDonald]

On 05-Sep-19 23:31, Krishna Myneni wrote:
> On Thu, 05 Sep 2019 14:07:25 +0100, Alex McDonald wrote:
>
> ...
>> This is a discussion with little if any merit. Words have unique
>> addresses, and they can have no to many names that are easily remembered
>> handles for those addresses. Everything else is hair splitting.
>
> I disagree that it is hair splitting. Nor is it "bikeshedding". There is

You're right, I was being a little harsh.

> confusion about the meaning of "nt" as defined in the standard. Now, the
> talk about returning "nt"s for definitions which are created with :NONAME
> introduces a logical inconsistency with the standard, which apparently
> people in this discussion would prefer to ignore. Ignoring this is what
> is wasting everyone's time, including mine.
>
> If the preferred approach is to just leave open-ended the interpretation
> of "nt", and disregard the language in the standard, then that could be a
> valid strategy to say that "nt" is a to-be established specification at a
> later date. But this should be stated explicitly. Otherwise, it makes
> little sense to talk about words which return "nt"s when no one can offer
> a consistent and precise definition of "nt". If you would care to offer
> one, please do so.
>

Yes, I'll try. There are 3 spaces that the system addresses;

3.3.1 Name space
3.3.2 Code space
3.3.3 Data space

The code space is where we have

1. words (identified by address)
2. tokens (an EXECUTEable or COMPILE,able address, XT)
3. definitions (a collection of words)

The data space has

1. words (identified by address)

The name space has

1. names (a string without any semantics; those are carried by the name
token)
2. name tokens (an address that contains additional information about a
name, including but not limited to addresses of words, tokens and
definitions in the other spaces, NT).
3. dictionaries (that implements 1 and 2).

It needs more work, but it is possible to classify accurately and still
use the words (in the non-Forth sense) that we have traditionally used.


--
Alex

[Krishna Myneni]

On Fri, 06 Sep 2019 14:05:56 +0100, Alex McDonald wrote:

> On 05-Sep-19 23:31, Krishna Myneni wrote:

...

>> If the preferred approach is to just leave open-ended the
>> interpretation of "nt", and disregard the language in the standard,
>> then that could be a valid strategy to say that "nt" is a to-be
>> established specification at a later date. But this should be stated
>> explicitly. Otherwise, it makes little sense to talk about words which
>> return "nt"s when no one can offer a consistent and precise definition
>> of "nt". If you would care to offer one, please do so.
>>
>>
> Yes, I'll try. There are 3 spaces that the system addresses;
>
>

...

> The name space has
>
> 1. names (a string without any semantics; those are carried by the name
> token)
> 2. name tokens (an address that contains additional information about a
> name, including but not limited to addresses of words, tokens and
> definitions in the other spaces, NT).

Can 2 encompass definitions created by :NONAME ?

Anton has recently stated, "The nt does not identify the name, but the
named word (or named definition, if you prefer), which (unlike the name)
has an interpretation semantics and a compilation semantics."

See http://forth-standard.org/standard/tools#contribution-109

That statement appears to be consistent with your description above, and
it is consistent with my understanding that the name token is not just a
pointer to the name string, which would make it of limited use.

Krishna

[Alex McDonald]

On 06-Sep-19 23:20, Krishna Myneni wrote:
>> 2. name tokens (an address that contains additional information about a
>> name, including but not limited to addresses of words, tokens and
>> definitions in the other spaces, NT).
> Can 2 encompass definitions created by :NONAME ?

Yes.

--
Alex

[dxforth]

On Friday, 6 September 2019 22:46:31 UTC+10, Alex McDonald wrote:
> On 06-Sep-19 11:25, dxforth wrote:
> > On Friday, 6 September 2019 18:18:58 UTC+10, Alex McDonald wrote:

> >> ...

> >> What new practice?
> >
> > Executing IMMEDIATE in the middle of compiling a colon definition.
>
> What do you mean by "the middle of a definition"?

"middle of a colon definition" being the original example you gave:

: gen1 : immediate postpone ; ;

>
> create bar immediate
>
> I can't see a middle.

Very good.

>
> : foo create , immediate does> @ ;
>
> Where is the "middle of the definition" in FOO? How do I make a CREATEd
> word immediate, or do I take your word for it and not bother because I'm
> executing IMMEDIATE in the "middle of a definition"?

I see no colon definition there.

>
> >
> >> I think you're misunderstanding what happens and when.
> >
> > I think you're misunderstanding what ANS was all about.
> >
> >>>> Which of GEN1 or BAR is the /most recent definition/?
> >>>
> >>> Ambiguous - it was never common practice to do that.
> >>
> >> It has been common practise to apply IMMEDIATE to words since the dawn
> >> of Forth.
> >
> > Then presumably you know what the common practice usage is. Perhaps you
> > want to make the ANS spec idiot-proof? In that case I would suggest only
> > a hermit would need it since how to implement or use IMMEDIATE is easily
> > found by looking or asking. It's not as if these things had never been
> > done before.
> >
>
> So why does iForth do it differently from others? Is Marcel Hendrix an
> idiot hermit?

I don't have iForth but from the examples shown so far I don't see Marcel
has done anything that contradicts 'common practice' usage of IMMEDIATE.
Had ANS intended something more by "most recent definition", I've little
doubt they would have told you. It wasn't in their interest to make ANS
ambiguous - though it may well be in the interests of certain commentators
on c.l.f.

[Krishna Myneni]

While the standard (Forth-2012) does not prohibit a Forth system from
providing name tokens for :NONAME definitions, on the whole I think it is
a bad idea. Because of an "nt"s definition, it tends to sow confusion
about whether words which work on nt's will work for the :NONAME
definitions, and may not be consistent from system to system, making it
harder to write portable code. Other questions come up, like does
TRAVERSE-WORDLIST iterate through the "nt"s of :NONAME definitions? The
standard does not say anything about this.

Krishna

[Krishna Myneni]

On Thu, 05 Sep 2019 23:01:52 -0700, A. K. wrote:

> Am Freitag, 6. September 2019 00:31:08 UTC+2 schrieb Krishna Myneni:

> ... There

>> is confusion about the meaning of "nt" as defined in the standard. Now,
>> the talk about returning "nt"s for definitions which are created with
>> :NONAME introduces a logical inconsistency with the standard, which
>> apparently people in this discussion would prefer to ignore. Ignoring
>> this is what is wasting everyone's time, including mine.
>
>
> NTs appear only in the optional Programmung Tools Wordset.
>
> Now they are enthusiastically driven into Core without necessity.

That's not quite true. :NONAME appears in CORE Extensions wordset. Also,
there is no standard way to obtain the "nt" for a named definition
without using TRAVERSE-WORDLIST from the Programming Tools wordset.
Without the Programming Tools wordset, the "nt" is invisible to the
programmer.

Krishna

[Mark William Humphries]

I think :NONAME was a bad idea to begin with.

[dxforth]

On Saturday, 7 September 2019 15:03:07 UTC+10, Mark William Humphries wrote:
> ...

> I think :NONAME was a bad idea to begin with.

Would you care to expand on that?

[Mark William Humphries]

I believe if it needs a header, it should have a name. If it doesn't need a header, then an address (/XT) should suffice.

If the goal is to save on target memory, then either use a tethered Forth and keep the headers on the host,
or have a utility word to selectively strip headers out when generating the target image.

[Coos Haak]

Op Sat, 7 Sep 2019 00:22:27 -0700 (PDT) schreef Mark William Humphries:

> Le samedi 7 septembre 2019 13:25:28 UTC+8, dxforth a écrit :
>> On Saturday, 7 September 2019 15:03:07 UTC+10, Mark William Humphries wrote:
>>> ...
>>> I think :NONAME was a bad idea to begin with.
>>
>> Would you care to expand on that?
>

> If it doesn't need a header, then an address (/XT) should suffice.

That's just what :NONAME does. So, what is your problem?

groet Coos