I prepared a proposal: New words: latest-name and latest-name-in [1]

In a nutshell:

LATEST-NAME-IN ( wid -- nt|0 )
Remove the word list identifier wid from the stack. If this word list is
empty, then return 0, otherwise return the name token nt for the
definition that was placed most recently into this word list.

LATEST-NAME ( -- nt )
Return the name token nt for the definition that was placed most
recently into the compilation word list, if such definition exists.
Otherwise throw exception code -80.

Feedback is welcome!

[1]
https://forth-standard.org/proposals/new-words-latest-name-and-latest-name-in?hideDiff#reply-1124

--
Ruvim

In article <uh5vno$36el4$1@dont-email.me>,
Ruvim <ruvim.pinka@gmail.com> wrote:
>I prepared a proposal: New words: latest-name and latest-name-in [1]
>
>In a nutshell:
>
>LATEST-NAME-IN ( wid -- nt|0 )
>Remove the word list identifier wid from the stack. If this word list is
>empty, then return 0, otherwise return the name token nt for the
>definition that was placed most recently into this word list.
>
>LATEST-NAME ( -- nt )
>Return the name token nt for the definition that was placed most
>recently into the compilation word list, if such definition exists.
>Otherwise throw exception code -80.
>
>Feedback is welcome!

I hate to see NAME here. I advocate dea (dictionary entry address)
since 1993 , working on the transputer Forth with Marcel Hendrix.
There were N fields and N^2 transformation and I have had
enough of it.

I recently wrote a design to lispificate / dynamicate Forth.
In this idea all items are dynamically located.
The first step is to ALLOCATE all name strings,
filling the name fields with a dynamic memory pointer.
The first benefit is that you can replace DROP by a Chinese equivalent
name etc. and have a Chinese friendly Forth.
......
The process ends with dynamically allocating all the headers
and a total dynamical Forth.

[ Then you can fill in the source field
with a dynamically allocated source string.
You then can edit the source and compile and change the code,
ultimately transforming the Forth from inside itself.
This was the original idea of "computer intelligence Forth"
and I have not really giving up on it. ]

***********************************************************
* Names are SO not determining the identity of a word. *
***********************************************************

I'm not against your proposal, only the names are wrong.

>LATEST ( wid -- dea|0 )
LATEST ( -- dea )

>[1]
>https://forth-standard.org/proposals/new-words-latest-name-and-latest-name-in?hideDiff#reply-1124
>Ruvim

Groetjes Albert

P.S. I use LATEST all over the place. I have a hard time to imagine
a use for >LATEST. Unless ..

Only define >LATEST. LATEST might be controversial so you avoid
standardising it.
On the top of the file you then can say
: LATEST CURRENT @ >LATEST ;
And get it over with.
Same situation as with
: NOT 0= ;
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On 2023-10-23 15:04, albert wrote:
> In article <uh5vno$36el4$1@dont-email.me>,
> Ruvim <ruvim.pinka@gmail.com> wrote:
>> I prepared a proposal: New words: latest-name and latest-name-in [1]
>>
>> In a nutshell:
>>
>> LATEST-NAME-IN ( wid -- nt|0 )
>> Remove the word list identifier wid from the stack. If this word list is
>> empty, then return 0, otherwise return the name token nt for the
>> definition that was placed most recently into this word list.
>>
>> LATEST-NAME ( -- nt )
>> Return the name token nt for the definition that was placed most
>> recently into the compilation word list, if such definition exists.
>> Otherwise throw exception code -80.
>>
>> Feedback is welcome!
>
> I hate to see NAME here. I advocate dea (dictionary entry address)
> since 1993 , working on the transputer Forth with Marcel Hendrix.
> There were N fields and N^2 transformation and I have had
> enough of it.

"DEA" is an acronym. It's better to use a full English word if appropriate.

"NAME" has a long history. It denoted NFA, and now it denotes a name
token, which is successor of NFA — in all words except "PARSE-NAME", for
example "FIND-NAME", "FIND-NAME-IN", "NAME>COMPILE", etc.

There is no point in replacing "NAME" in all these words.
At the same time, naming for new words must be in consistence with
existing words.

[...]
>
> ***********************************************************
> * Names are SO not determining the identity of a word. *
> ***********************************************************
>
> I'm not against your proposal, only the names are wrong.
>
> >LATEST ( wid -- dea|0 )
> LATEST ( -- dea )

The first name is not consistent with other similar names.

And words with the second name already exist in many Forth systems, and
they behavior varies.

>
>> [1]
>> https://forth-standard.org/proposals/new-words-latest-name-and-latest-name-in?hideDiff#reply-1124
>> Ruvim
>
> Groetjes Albert
>
> P.S. I use LATEST all over the place. I have a hard time to imagine
> a use for >LATEST. Unless ..
>
> Only define >LATEST. LATEST might be controversial so you avoid
> standardising it.
> On the top of the file you then can say
> : LATEST CURRENT @ >LATEST ;

It's will be slightly longer.
In my proposal this word never returns 0, but throws an exception instead.

> And get it over with.
> Same situation as with
> : NOT 0= ;

--
Ruvim

On Monday, October 23, 2023 at 5:37:30 PM UTC+2, Ruvim wrote:
[..]
> "NAME" has a long history. It denoted NFA, and now it denotes a name
> token, which is successor of NFA — in all words except
> "PARSE-NAME", for example "FIND-NAME", "FIND-NAME-IN", "NAME>COMPILE", etc.
------------------------

Why in heavens name, call it PARSE-NAME ?

PARSE-NAME CORE EXT
( <spaces>name<space> -- c-addr u )
Skip leading space delimiters. Parse name delimited by a space.
c-addr is the address of the selected string within the input buffer
and u is its length in characters. If the parse area is empty or contains
only white space, the resulting string has length zero.

Apart from the above, it makes no sense and is counter-intuitive?

-marcel

On 2023-10-23 16:44, Marcel Hendrix wrote:
> On Monday, October 23, 2023 at 5:37:30 PM UTC+2, Ruvim wrote:
> [..]
>> "NAME" has a long history. It denoted NFA, and now it denotes a name
>> token, which is successor of NFA — in all words except
>> "PARSE-NAME", for example "FIND-NAME", "FIND-NAME-IN", "NAME>COMPILE", etc.
> ------------------------
>
> Why in heavens name, call it PARSE-NAME ?

Anton wrote [2]: "PARSE-NAME was originally proposed as PARSE-WORD, but
that name has conflicting behaviour in some widely-used systems, so
PARSE-NAME was chosen."

In my message at [2], I was wrong that PARSE-NAME did not have conflicts
in 2005. "NAME" was used to denote "NFA" long before that.

So it was a bad choice even in 2005. Another example of a bad name
choice is "BUFFER:", which too close to "BUFFER".

For "BUFFER:" I suggest the synonym "REGION" (as in "a memory region").
Without a colon in the name, since all other similar defining words
don't have a colon in their names.

Instead of "PARSE-NAME" — we can have "PARSE-LEXEME"

>
> PARSE-NAME CORE EXT
> ( <spaces>name<space> -- c-addr u )
> Skip leading space delimiters. Parse name delimited by a space.
> c-addr is the address of the selected string within the input buffer
> and u is its length in characters. If the parse area is empty or contains
> only white space, the resulting string has length zero.
>
> Apart from the above, it makes no sense and is counter-intuitive?
>
> -marcel

[2] https://forth-standard.org/standard/core/PARSE-NAME#contribution-92

--
Ruvim

Marcel Hendrix <mhx@iae.nl> writes:
>Why in heavens name, call it PARSE-NAME ?

Water down the river. But if you are interested, you can read about
it at <http://www.forth200x.org/parse-name.html>. And there it says:

|Several systems have implemented a PARSE-WORD compatible with this
|specification, e.g., Gforth and Quartus.
| |However, several systems have implemented words called PARSE-WORD that
|are incompatible with this specification (e.g., MPE's Forths,
|MinForth, CHForth, F83, Jforth, 4th; Mops is also incompatible, but in
|a less problematic way), and Stephen Pelc indicated that MPE's Forth
|would never implement this word with the name PARSE-WORD.
| |Therefore, a new name is needed for this functionality, and a
|strawpoll indicated the most support for PARSE-NAME.

And looking for the strawpoll, I find in
<2005Apr22.104613@mips.complang.tuwien.ac.at>:

|Well, in the meantime more people have expressed their opinion:
| |NextWord (conflict: exists with different meaning in Win32Forth)
|TOKEN
| Supported by: Alex McDonald
| Could live with it: Bernd Paysan
| Strongly opposed: Michael L Gassanenko
|NAME (existing practice: exists with this meaning in Gforth)
| Supported by: Coos Haak
| Supported by: Albert van der Horst
| Could live with it: Bernd Paysan
| (Michael Gassenenko points out that it does not fit with >NAME NAME>)
|EXTRACTWORD
|EXTRACT-WORD
| Supported by: Ward McFarland
|GET-WORD
|GET-NAME
|GET-TOKEN
|PARSE-NAME
| Supported by: Stephen Pelc
| Second choice: Albert van der Horst
| Could live with it: Ward McFarland
| Could also support: Alex McDonald
| Could live with it: Marcel Hendrix
| Can live with it: David N. Williams
| Supported by: Anton Ertl
|PARSE-STREAM
| |So I have decided to go forward with PARSE-NAME and I will send an RfD
|for it soon.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2023: https://euro.theforth.net/2023

Ruvim schrieb am Montag, 23. Oktober 2023 um 16:25:00 UTC+2:
> I prepared a proposal: New words: latest-name and latest-name-in [1]
>
> In a nutshell:
>
> LATEST-NAME-IN ( wid -- nt|0 )
> Remove the word list identifier wid from the stack. If this word list is
> empty, then return 0, otherwise return the name token nt for the
> definition that was placed most recently into this word list.
>
> LATEST-NAME ( -- nt )
> Return the name token nt for the definition that was placed most
> recently into the compilation word list, if such definition exists.
> Otherwise throw exception code -80.
>
> Feedback is welcome!

I fail to see a use case.

IMO the inner mechanisms of compilers shouldn't be cemented
by so-called standards.

On 2023-10-23 20:03, minforth wrote:
> Ruvim schrieb am Montag, 23. Oktober 2023 um 16:25:00 UTC+2:
>> I prepared a proposal: New words: latest-name and latest-name-in [1]
>>
>> In a nutshell:
>>
>> LATEST-NAME-IN ( wid -- nt|0 )
>> Remove the word list identifier wid from the stack. If this word list is
>> empty, then return 0, otherwise return the name token nt for the
>> definition that was placed most recently into this word list.
>>
>> LATEST-NAME ( -- nt )
>> Return the name token nt for the definition that was placed most
>> recently into the compilation word list, if such definition exists.
>> Otherwise throw exception code -80.
>>
>> Feedback is welcome!
>
> I fail to see a use case.

In the section "Typical use" (by the link), two use case examples are shown.

Vocabulary for structure definition:

: struct: ( "name" -- wid.current.old u.offset )
vocabulary
get-current
also latest-name name> execute
definitions
0
;

Init a deferred definition:

\ in the application's vocabulary
: it ( -- xt ) latest-name name>interpret ;

defer foo

: bar ... ; it is foo

A decorator example:

: [!] ( "name" -- )
latest-name dup >r
name>string ['] : execute-parsing
r> name> ' execute
postpone ;
;

: make-pretty ( xt -- )
[: ." (I got decorated)" ;] compile, compile,
;

: foo ." (I'm ordinary)" ;
[!] make-pretty

foo \ "(I got decorated)(I'm ordinary)"

> IMO the inner mechanisms of compilers shouldn't be cemented
> by so-called standards.

The proposed API cements exactly zero inner mechanisms of compilers.

The only additional burden is to store the latest word in the word list
structure. But anyway, almost all Forth systems do it. If not — the
system is free to not provide this API.

--
Ruvim

On 24/10/2023 1:24 am, Ruvim wrote:
> I prepared a proposal: New words: latest-name and latest-name-in [1]
>
> In a nutshell:
>
> LATEST-NAME-IN ( wid -- nt|0 )
> Remove the word list identifier wid from the stack. If this word list is empty, then return 0, otherwise return the name token nt for the definition that was placed most recently into this word list.
>
> LATEST-NAME ( -- nt )
> Return the name token nt for the definition that was placed most recently into the compilation word list, if such definition exists. Otherwise throw exception code -80.
>
> Feedback is welcome!

Why the exception on LATEST-NAME - how many forths do that?

Ruvim schrieb am Montag, 23. Oktober 2023 um 22:49:04 UTC+2:
> On 2023-10-23 20:03, minforth wrote:
> > Ruvim schrieb am Montag, 23. Oktober 2023 um 16:25:00 UTC+2:
> >> I prepared a proposal: New words: latest-name and latest-name-in [1]
> >>
> >> In a nutshell:
> >>
> >> LATEST-NAME-IN ( wid -- nt|0 )
> >> Remove the word list identifier wid from the stack. If this word list is
> >> empty, then return 0, otherwise return the name token nt for the
> >> definition that was placed most recently into this word list.
> >>
> >> LATEST-NAME ( -- nt )
> >> Return the name token nt for the definition that was placed most
> >> recently into the compilation word list, if such definition exists.
> >> Otherwise throw exception code -80.
> >>
> >> Feedback is welcome!
> >
> > I fail to see a use case.
> In the section "Typical use" (by the link), two use case examples are shown.

Those are examples for compiler extensions.

> > IMO the inner mechanisms of compilers shouldn't be cemented
> > by so-called standards.
> The proposed API cements exactly zero inner mechanisms of compilers.

I don't think so. Many Forths have LAST which isn't standardized either.
> The only additional burden is to store the latest word in the word list
> structure. But anyway, almost all Forth systems do it. If not — the
> system is free to not provide this API.

Perhaps a new wordset COMPILER-EXTENSION would be better.
Also as a good place for recognizers, whenever that proposal makes it.

On 24/10/2023 2:51 pm, dxf wrote:
> On 24/10/2023 1:24 am, Ruvim wrote:
>> I prepared a proposal: New words: latest-name and latest-name-in [1]
>>
>> In a nutshell:
>>
>> LATEST-NAME-IN ( wid -- nt|0 )
>> Remove the word list identifier wid from the stack. If this word list is empty, then return 0, otherwise return the name token nt for the definition that was placed most recently into this word list.
>>
>> LATEST-NAME ( -- nt )
>> Return the name token nt for the definition that was placed most recently into the compilation word list, if such definition exists. Otherwise throw exception code -80.
>>
>> Feedback is welcome!
>
> Why the exception on LATEST-NAME - how many forths do that?

Never mind - I've since seen the reference implementation on forth-standard.org.

In article <a7cd17fc-6257-471c-ae11-2aa1b14b33dcn@googlegroups.com>,
minforth <minforth@arcor.de> wrote:
>Ruvim schrieb am Montag, 23. Oktober 2023 um 16:25:00 UTC+2:
>> I prepared a proposal: New words: latest-name and latest-name-in [1]
>>
>> In a nutshell:
>>
>> LATEST-NAME-IN ( wid -- nt|0 )
>> Remove the word list identifier wid from the stack. If this word list is
>> empty, then return 0, otherwise return the name token nt for the
>> definition that was placed most recently into this word list.
>>
>> LATEST-NAME ( -- nt )
>> Return the name token nt for the definition that was placed most
>> recently into the compilation word list, if such definition exists.
>> Otherwise throw exception code -80.
>>
>> Feedback is welcome!
>
>I fail to see a use case.
>
>IMO the inner mechanisms of compilers shouldn't be cemented
>by so-called standards.

Hear! Hear!

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

In article <uh63vl$37cua$1@dont-email.me>,
Ruvim <ruvim.pinka@gmail.com> wrote:
>On 2023-10-23 15:04, albert wrote:
>> In article <uh5vno$36el4$1@dont-email.me>,
>> Ruvim <ruvim.pinka@gmail.com> wrote:
>>> I prepared a proposal: New words: latest-name and latest-name-in [1]
>>>
>>> In a nutshell:
>>>
>>> LATEST-NAME-IN ( wid -- nt|0 )
>>> Remove the word list identifier wid from the stack. If this word list is
>>> empty, then return 0, otherwise return the name token nt for the
>>> definition that was placed most recently into this word list.
>>>
>>> LATEST-NAME ( -- nt )
>>> Return the name token nt for the definition that was placed most
>>> recently into the compilation word list, if such definition exists.
>>> Otherwise throw exception code -80.
>>>
>>> Feedback is welcome!
>>
>> I hate to see NAME here. I advocate dea (dictionary entry address)
>> since 1993 , working on the transputer Forth with Marcel Hendrix.
>> There were N fields and N^2 transformation and I have had
>> enough of it.
>
>"DEA" is an acronym. It's better to use a full English word if appropriate.

This a slight disadvantage. However it conflicts with nothing.
There are Forth names that are abbreviations:
R/O R/W SCR TIB SM/REM UM/MOD
In the 30 years I have used DEA nobody has come up that catches the
concept properly, and certainly anybody who has come up with a name that
catches the concept improperly have found that is subject to confusion and
infighting. On the other hand *nobody* has used "dea" in a conflicting
way.

"
The DEA of a word identifies the word internally. It should be
possible for the system to find all the properies of word
knowing its DEA. In particular the executable code and its
name (if it has a name)
" ^^^^^^^^^^^^^^^^

It bears repeating:

***********************************************************
* Names are SO not determining the identity of a word. *
***********************************************************

>
>"NAME" has a long history. It denoted NFA, and now it denotes a name
>token, which is successor of NFA — in all words except "PARSE-NAME", for
>example "FIND-NAME", "FIND-NAME-IN", "NAME>COMPILE", etc.
>
>There is no point in replacing "NAME" in all these words.
>At the same time, naming for new words must be in consistence with
>existing words.
That is a non sequitur. In particular FIND-NAME is an example why
the string NAME is a separate concept of the dea.
Compare :
FOUND ( sc -- dea )
Look up the sc (addr len) in the current search order.
Return *the* address dea, the address that rules them all.

>
>
>[...]
>>
>> ***********************************************************
>> * Names are SO not determining the identity of a word. *
>> ***********************************************************
>>
>> I'm not against your proposal, only the names are wrong.
>>
>> >LATEST ( wid -- dea|0 )
>> LATEST ( -- dea )
>
>The first name is not consistent with other similar names.
>
>And words with the second name already exist in many Forth systems, and
>they behavior varies.

Seriously? What with S>D >R U> EKEY>CHAR
You are trying to win a debate here at any price. That doesnot get you
points in a standard commission that must compromise.
It is not a fraternety debate club.

>>> [1]
>>> https://forth-standard.org/proposals/new-words-latest-name-and-latest-name-in?hideDiff#reply-1124
>>> Ruvim
>>
>> Groetjes Albert
>>
>> P.S. I use LATEST all over the place. I have a hard time to imagine
>> a use for >LATEST. Unless ..
>>
>> Only define >LATEST. LATEST might be controversial so you avoid
>> standardising it.
>> On the top of the file you then can say
>> : LATEST CURRENT @ >LATEST ;
>
>It's will be slightly longer.
>In my proposal this word never returns 0, but throws an exception instead.
>
>> And get it over with.
>> Same situation as with
>> : NOT 0= ;

I can't getting the point accross.
The problem with LATEST that the obvious solution doesn't work.
The naive solution reading iso93 is returning an xt.
So what thingy is LATEST to return?

>--
>Ruvim
>

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

In article <uh6m7s$3cc1o$1@dont-email.me>,
Ruvim <ruvim.pinka@gmail.com> wrote:
<SNIP>
>A decorator example:
>
> : [!] ( "name" -- )
> latest-name dup >r
> name>string ['] : execute-parsing
> r> name> ' execute
> postpone ;
> ;
>
>
> : make-pretty ( xt -- )
> [: ." (I got decorated)" ;] compile, compile,
> ;
>
> : foo ." (I'm ordinary)" ;
> [!] make-pretty
>
> foo \ "(I got decorated)(I'm ordinary)"
>

In ciforth (leaving out the OK's)

WANT decorated {
: foo "(I'm ordinary)" TYPE ;
{ "(I got decorated)" TYPE } 'foo decorated
foo
(I got decorated)(I'm ordinary)
'foo undecorated
foo
(I'm ordinary)

The use case of `decorated is to add temporary debug
information to a complicated system, especially if
Heisenbugs prevent you to insert debugging code.

An example of a recent use in a Make Another Lisp project.
{ DUP EMIT CO DUP DUP SIZE TYPE &| EMIT } '$C+a decorated
$C+a appends a character to an ALLOCATEd string
What is after CO (Chuck Moores name is ;: ) is code
that is executed after the word decorated executes.
An example of output would be
AanothernameA|
confirming that the character is properly appended to the
ALLOCATE string, that was formerly apparently "anothername".

You can use the clunky :NONAME for { and ; for }
but the following won't fly.

: doit { "(I got decorated)" TYPE } 'foo decorated ;
doit
>
>--
>Ruvim
>

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

On 2023-10-24 07:43, dxf wrote:
> On 24/10/2023 2:51 pm, dxf wrote:
>> On 24/10/2023 1:24 am, Ruvim wrote:
>>> I prepared a proposal: New words: latest-name and latest-name-in [1]
>>>
>>> In a nutshell:
>>>
>>> LATEST-NAME-IN ( wid -- nt|0 )
>>> Remove the word list identifier wid from the stack. If this word list is empty, then return 0, otherwise return the name token nt for the definition that was placed most recently into this word list.
>>>
>>> LATEST-NAME ( -- nt )
>>> Return the name token nt for the definition that was placed most recently into the compilation word list, if such definition exists. Otherwise throw exception code -80.
>>>
>>> Feedback is welcome!
>>
>> Why the exception on LATEST-NAME - how many forths do that?
>
> Never mind - I've since seen the reference implementation on forth-standard.org.
>
>

Let me explain for other readers.

It does not matter how many Forth systems do that, since it's a new
word, and it is intended for users, not for the internal needs of the
system (of course the system may use it, but is not required to do so).

What matters is how many users/programs check the returned value on
zero, and why they do it. As I see, programs almost never check the
returned value from such words. It means, this word shall throw an
exception instead of return 0.

--
Ruvim

On 2023-10-24 09:16, albert wrote:
> In article <uh6m7s$3cc1o$1@dont-email.me>,
> Ruvim <ruvim.pinka@gmail.com> wrote:
> <SNIP>
>> A decorator example:
>>
>> : [!] ( "name" -- )
>> latest-name dup >r
>> name>string ['] : execute-parsing
>> r> name> ' execute
>> postpone ;
>> ;
>>
>>
>> : make-pretty ( xt -- )
>> [: ." (I got decorated)" ;] compile, compile,
>> ;
>>
>> : foo ." (I'm ordinary)" ;
>> [!] make-pretty
>>
>> foo \ "(I got decorated)(I'm ordinary)"
>>
>
> In ciforth (leaving out the OK's)
>
> WANT decorated {
> : foo "(I'm ordinary)" TYPE ;
> { "(I got decorated)" TYPE } 'foo decorated

The idea of a special syntax for decoration is that you don't need to
repeat the name of the word that is decorated.

Otherwise it's just a wrapper, which can be always implemented directly.

> foo
> (I got decorated)(I'm ordinary)
> 'foo undecorated
> foo
> (I'm ordinary)
>
> The use case of `decorated is to add temporary debug
> information to a complicated system, especially if
> Heisenbugs prevent you to insert debugging code.
>
> An example of a recent use in a Make Another Lisp project.
> { DUP EMIT CO DUP DUP SIZE TYPE &| EMIT } '$C+a decorated
> $C+a appends a character to an ALLOCATEd string
> What is after CO (Chuck Moores name is ;: ) is code
> that is executed after the word decorated executes.
> An example of output would be
> AanothernameA|
> confirming that the character is properly appended to the
> ALLOCATE string, that was formerly apparently "anothername".
>
> You can use the clunky :NONAME for { and ; for }
> but the following won't fly.
>
> : doit { "(I got decorated)" TYPE } 'foo decorated ;
> doit

It can work with quotations.

But your implementation is too system specific — it requires a
capability to change behavior of any word.

--
Ruvim

On 2023-10-24 06:49, minforth wrote:
> Ruvim schrieb am Montag, 23. Oktober 2023 um 22:49:04 UTC+2:
>> On 2023-10-23 20:03, minforth wrote:
>>> Ruvim schrieb am Montag, 23. Oktober 2023 um 16:25:00 UTC+2:
>>>> I prepared a proposal: New words: latest-name and latest-name-in [1]
>>>>
>>>> In a nutshell:
>>>>
>>>> LATEST-NAME-IN ( wid -- nt|0 )
>>>> Remove the word list identifier wid from the stack. If this word list is
>>>> empty, then return 0, otherwise return the name token nt for the
>>>> definition that was placed most recently into this word list.
>>>>
>>>> LATEST-NAME ( -- nt )
>>>> Return the name token nt for the definition that was placed most
>>>> recently into the compilation word list, if such definition exists.
>>>> Otherwise throw exception code -80.
>>>>
>>>> Feedback is welcome!
>>>
>>> I fail to see a use case.
>> In the section "Typical use" (by the link), two use case examples are shown.
>
> Those are examples for compiler extensions.
>

>>> IMO the inner mechanisms of compilers shouldn't be cemented
>>> by so-called standards.
>> The proposed API cements exactly zero inner mechanisms of compilers.
>
> I don't think so. Many Forths have LAST which isn't standardized either.

They continue to use their LAST or whatever they used before.

The proposed words are intended for *programs*. The system is not
required to use these words at all.

Even if the system provides these words, this does not in any way limit
the internal mechanisms of its compiler.

>> The only additional burden is to store the latest word in the word list
>> structure. But anyway, almost all Forth systems do it. If not — the
>> system is free to not provide this API.
>
> Perhaps a new wordset COMPILER-EXTENSION would be better.
> Also as a good place for recognizers, whenever that proposal makes it.

It's true for recognizers, since a program can affect the behavior of
the Forth text interpreter via Recognizer API (and even use it for its
own purposes).

But the words LATEST-NAME-IN and LATEST-NAME simply provide some
information from word lists, like the words FIND-NAME-IN or
TRAVERSE-WORDLIST do.

--
Ruvim

In article <uh89cq$3rfe1$2@dont-email.me>,
Ruvim <ruvim.pinka@gmail.com> wrote:
<SNIP>
>> The use case of `decorated is to add temporary debug
>> information to a complicated system, especially if
>> Heisenbugs prevent you to insert debugging code.

>The idea of a special syntax for decoration is that you don't need to
>repeat the name of the word that is decorated.
>
>Otherwise it's just a wrapper, which can be always implemented directly.

So I have this answered beforehand. It doesn't help with a Heisenbug.

>
>But your implementation is too system specific — it requires a
>capability to change behavior of any word.

What can I say.
The python people can do it. ciforth can do it. gdb can do it.
It is no excuse if a system is not powerful enough.
>
>--
>Ruvim
>

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

On 2023-10-24 08:37, albert wrote:
> In article <uh63vl$37cua$1@dont-email.me>,
> Ruvim <ruvim.pinka@gmail.com> wrote:
>> On 2023-10-23 15:04, albert wrote:
>>> In article <uh5vno$36el4$1@dont-email.me>,
>>> Ruvim <ruvim.pinka@gmail.com> wrote:
>>>> I prepared a proposal: New words: latest-name and latest-name-in [1]
>>>>
>>>> In a nutshell:
>>>>
>>>> LATEST-NAME-IN ( wid -- nt|0 )
>>>> Remove the word list identifier wid from the stack. If this word list is
>>>> empty, then return 0, otherwise return the name token nt for the
>>>> definition that was placed most recently into this word list.
>>>>
>>>> LATEST-NAME ( -- nt )
>>>> Return the name token nt for the definition that was placed most
>>>> recently into the compilation word list, if such definition exists.
>>>> Otherwise throw exception code -80.
>>>>
>>>> Feedback is welcome!
>>>
>>> I hate to see NAME here. I advocate dea (dictionary entry address)
>>> since 1993 , working on the transputer Forth with Marcel Hendrix.
>>> There were N fields and N^2 transformation and I have had
>>> enough of it.
>>
>> "DEA" is an acronym. It's better to use a full English word if appropriate.
>
> This a slight disadvantage. However it conflicts with nothing.

I'm not against the term "DEA". It could be acceptable.

But at the moment, the term "name token" is already established, as well
as its designation "name" in the names of words.

What is wrong with that? Why is it worth changing to "dea"?

> There are Forth names that are abbreviations:
> R/O R/W SCR TIB SM/REM UM/MOD
> In the 30 years I have used DEA nobody has come up that catches the
> concept properly, and certainly anybody who has come up with a name that
> catches the concept improperly have found that is subject to confusion and
> infighting. On the other hand *nobody* has used "dea" in a conflicting
> way.
>
> "
> The DEA of a word identifies the word internally. It should be
> possible for the system to find all the properies of word
> knowing its DEA. In particular the executable code and its
> name (if it has a name)
> " ^^^^^^^^^^^^^^^^
>
> It bears repeating:
>
> ***********************************************************
> * Names are SO not determining the identity of a word. *
> ***********************************************************

I agree. A word name does not identify the word.
A name token identifies the word, by its definition:

A name token is a single-cell value that identifies a named Forth
definition.

In this context the term "token" does not mean a character sequence.
In a general sense, it is "something serving as an expression of
something else" -- https://en.wiktionary.org/wiki/token#Noun

>>
>> "NAME" has a long history. It denoted NFA, and now it denotes a name
>> token, which is successor of NFA — in all words except "PARSE-NAME", for
>> example "FIND-NAME", "FIND-NAME-IN", "NAME>COMPILE", etc.
>>
>> There is no point in replacing "NAME" in all these words.
>> At the same time, naming for new words must be in consistence with
>> existing words.
> That is a non sequitur. In particular FIND-NAME is an example why
> the string NAME is a separate concept of the dea.

In "FIND-NAME" , "NAME" denotes a name token rather than a character
string. And it's a thing that is found.

If I understand right, in English, "to find x" means that "x" is the
thing that is found on success. In this case the found thing is a name
token, that is denoted as "NAME".

> Compare :
> FOUND ( sc -- dea )
> Look up the sc (addr len) in the current search order.
> Return *the* address dea, the address that rules them all.

The notion of memory address is too system specific for this purpose.

For example, in some plausible Forth system it can be an index in the
array of headers.

>>
>> [...]
>>>
>>> ***********************************************************
>>> * Names are SO not determining the identity of a word. *
>>> ***********************************************************
>>>
>>> I'm not against your proposal, only the names are wrong.
>>>
>>> >LATEST ( wid -- dea|0 )
>>> LATEST ( -- dea )
>>
>> The first name is not consistent with other similar names.
>>
>> And words with the second name already exist in many Forth systems, and
>> they behavior varies.
>
> Seriously? What with S>D >R U> EKEY>CHAR

Well, the right example is ">BODY" ( xt -- a-addr )

But I would prefer to avoid new standard words with names starting with
">", if this word is not for a stack related word.

> You are trying to win a debate here at any price. That doesnot get you
> points in a standard commission that must compromise.
> It is not a fraternety debate club.

It looks like you want to give me a piece of advice. A public place is
not suitable for this ;)

I just wonder, what a compromise do you have in mind in this particular
case? I mean, a compromise between which positions?

>>>> [1]
>>>> https://forth-standard.org/proposals/new-words-latest-name-and-latest-name-in?hideDiff#reply-1124
>>>> Ruvim
>>>
>>> Groetjes Albert
>>>
>>> P.S. I use LATEST all over the place. I have a hard time to imagine
>>> a use for >LATEST. Unless ..
>>>
>>> Only define >LATEST. LATEST might be controversial so you avoid
>>> standardising it.
>>> On the top of the file you then can say
>>> : LATEST CURRENT @ >LATEST ;
>>
>> It's will be slightly longer.
>> In my proposal this word never returns 0, but throws an exception instead.
>>
>>> And get it over with.
>>> Same situation as with
>>> : NOT 0= ;
>
> I can't getting the point accross.
> The problem with LATEST that the obvious solution doesn't work.
> The naive solution reading iso93 is returning an xt.
> So what thingy is LATEST to return?

Sorry, I'm not following you here. I don't see how your question about
LATEST is related to my proposal.

--
Ruvim

In article <uh954j$4q87$1@dont-email.me>, Ruvim <ruvim.pinka@gmail.com> wrote:
>On 2023-10-24 08:37, albert wrote:
>> It bears repeating:
>>
>> ***********************************************************
>> * Names are SO not determining the identity of a word. *
>> ***********************************************************
>
>I agree. A word name does not identify the word.
>A name token identifies the word, by its definition:
>
> A name token is a single-cell value that identifies a named Forth
>definition.

Almost correct.

A name token is a single-cell value that identifies a Forth
definition. Note that it may not have a name.

>> I can't getting the point accross.
>> The problem with LATEST that the obvious solution doesn't work.
>> The naive solution reading iso93 is returning an xt.
>> So what thingy is LATEST to return?
>
>Sorry, I'm not following you here. I don't see how your question about
>LATEST is related to my proposal.

The answer is not what it is that is returned. The answer is how it
should be named:
Possibly answers:
A name token
B dea

In any case it must be an answer that identifies a
word/definition/you-know-what-I-mean.

>Ruvim

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

Ruvim schrieb am Dienstag, 24. Oktober 2023 um 13:36:11 UTC+2:
> On 2023-10-24 06:49, minforth wrote:
> > Perhaps a new wordset COMPILER-EXTENSION would be better.
> > Also as a good place for recognizers, whenever that proposal makes it.
>
> It's true for recognizers, since a program can affect the behavior of
> the Forth text interpreter via Recognizer API (and even use it for its
> own purposes).
>
> But the words LATEST-NAME-IN and LATEST-NAME simply provide some
> information from word lists, like the words FIND-NAME-IN or
> TRAVERSE-WORDLIST do.

FIND-NAME-IN is exotic but I can guess... ;-)

Anyhow IMO it needs really good arguments to increase Forth's already
overpopulated word zoo. It's more libraries we need.
But I don't want to be negative, you asked for thoughts.

On 25/10/2023 10:17 am, minforth wrote:
> Ruvim schrieb am Dienstag, 24. Oktober 2023 um 13:36:11 UTC+2:
>> On 2023-10-24 06:49, minforth wrote:
>>> Perhaps a new wordset COMPILER-EXTENSION would be better.
>>> Also as a good place for recognizers, whenever that proposal makes it.
>>
>> It's true for recognizers, since a program can affect the behavior of
>> the Forth text interpreter via Recognizer API (and even use it for its
>> own purposes).
>>
>> But the words LATEST-NAME-IN and LATEST-NAME simply provide some
>> information from word lists, like the words FIND-NAME-IN or
>> TRAVERSE-WORDLIST do.
>
> FIND-NAME-IN is exotic but I can guess... ;-)
>
> Anyhow IMO it needs really good arguments to increase Forth's already
> overpopulated word zoo.

Compiler extension is what 200x is mostly interested in.

> It's more libraries we need.

Apparently not but feel free to provide them. At a guess they will be met
with the same enthusiasm as was Hugh's and those before him. I put great
value on the libraries I include with DX-Forth. Other users very little.
Perhaps they need to find their own path - just as I did.

On Tuesday, October 24, 2023 at 2:40:51 PM UTC-5, none albert wrote:
> >> It bears repeating:
> >>
> >> ***********************************************************
> >> * Names are SO not determining the identity of a word. *
> >> ***********************************************************
>
> A name token is a single-cell value that identifies a Forth
> definition. Note that it may not have a name.

Two ideas that appeal to me (and likely only me) are:
1. Have standard behaviors, but not names. Users free to
assign whatever names that fit the context where the
behavior is used. COUNT and C@++ in my source have the
same behavior; which get used depends on the context where
applied. Your FOO with behavior xt:666 can be my BAR ; just
map if exchange of source code is desired.

2. Like postscript in general define words anonymously. Assign
name only if the behavior needs to persist.

Just mentioning this as Albert seems to have some leanings in
this direction.
--
me

dxf schrieb am Mittwoch, 25. Oktober 2023 um 03:18:47 UTC+2:
> On 25/10/2023 10:17 am, minforth wrote:
> > It's more libraries we need.
> Apparently not but feel free to provide them.

There is no standard API for any standard Forth system.

Other good guys test their code snippets against a number of
popular free Forth compilers, write wrappers, and provide
missing words.

I must be a lazy bad guy. :-)

On 2023-10-24 23:17, minforth wrote:
> Ruvim schrieb am Dienstag, 24. Oktober 2023 um 13:36:11 UTC+2:
>> On 2023-10-24 06:49, minforth wrote:
>>> Perhaps a new wordset COMPILER-EXTENSION would be better.
>>> Also as a good place for recognizers, whenever that proposal makes it.
>>
>> It's true for recognizers, since a program can affect the behavior of
>> the Forth text interpreter via Recognizer API (and even use it for its
>> own purposes).
>>
>> But the words LATEST-NAME-IN and LATEST-NAME simply provide some
>> information from word lists, like the words FIND-NAME-IN or
>> TRAVERSE-WORDLIST do.
>
> FIND-NAME-IN is exotic but I can guess... ;-)

Can you suggest something better? ))

It's a part of the Forth "living" standard already.

> Anyhow IMO it needs really good arguments to increase Forth's already
> overpopulated word zoo.

> It's more libraries we need.

I will say more — we need the *infrastructure* for libraries.

Using third party libraries in Forth is a pain, especially if you want
to do it regardless of a particular Forth system.

I have an idea of a core library that extends "include" and "require" to
allow them understanding URIs and load+cache files via the Internet on
the fly.

If the used Forth system does not provide the required capabilities, the
user can use another Forth system to just cache all libraries, and then
use the first one (without changing any source codes).

When this library exists, a more advanced package manager (and module
manager) can be developed on the top of this library.

Well we have https://theforth.net/package/f
But this package manager is tied to a single repository and requires too
much manual work.

> But I don't want to be negative, you asked for thoughts.

--
Ruvim