TRAVERSE-WORDLIST

[Krishna Myneni]

Well, I'm a little late to the party which I first proposed around 2012,
and which Alex McDonald actually made happen, but better late than never.
I finally got around to implementing TRAVERSE-WORDLIST in kforth64, and
it will soon appear in kforth32. The need for this word was made apparent
when David N. Williams and I were working on our modules framework -- the
word is mentioned in the document modular-forth.pdf (see ref. below):

<quote>
...
One area of planned development is to provide additional tools to Forth
authors, to aid with development of modules supporting name reuse.
Already, the simple tool SHOW-MODULES is very useful for a programmer to
view the available modules loaded in a Forth system. Other envisioned
tools will support the development and use of generic interfaces by
allowing the programmer to query for a list of name overlaps within
modules. Such tools include:

* display the names of all modules which provide a particular
name in their API,

s" <word_name>" MEMBER-OF

* display all API names which overlap between two given modules,

' <mod_A> ' <mod_B> NAMES-OVERLAP

* display a given module's dependencies,

' <mod_name> SHOW-DEPENDENCIES

... tools such as MEMBER-OF and NAMES-OVERLAP currently cannot be
implemented in standard Forth, due to the lack of a standard way of
traversing wordlists and obtaining word names. However, we expect such
features may be standardized in the near future since a number of Forth
systems already provide such features. A Request for Discussion (RfD) has
already been posted to the comp.lang.forth newsgroup for the
standardization of a word named TRAVERSE-WORDLIST . We are optimistic
that standardized infrastructure will be adopted in Forth systems to
support the development of such tools.
...
</quote>

I'm quite happy that it happened and TRAVERSE-WORDLIST became part of the
de-facto Forth standard. The inclusion of it in my Forth system means
that I can get on with adding planned features for our modules framework.

More generally, the Forth environment combined with the language gives us
powerful tools to query the environment and the code, and to write
utilities to give us a higher-level picture of the code (word)
dependencies, or optimization, or even system integrity checking.
TRAVERSE-WORDLIST can be a useful tool to develop such utilities. One
example that comes to mind is our recent discussion about the body
addresses for words, and how they are often invalid addresses for
parameter data associated with a word. I wrote a word called WL-INFO
using TRAVERSE-WORDLIST to display the name, precedence, xt, and body
address of all the words in a given wordlist. This type of environment
view will be useful in reimplementing >BODY to ensure that it returns
either a valid parameter address or zero. See below.

Krishna Myneni

Reference:

K. Myneni and D. N. Williams, A Forth Modules System with Name Reuse, 15
Feb. 2012,
https://github.com/mynenik/kForth-32/blob/master/doc/modular-forth.pdf

----
\ Example of using TRAVERSE-WORDLIST: WL-INFO
include ans-words
include strings

\ kForth-specific implementation of Forth-2012 NAME>STRING
\ (15.6.2.1909.40 in Tools Ext)
: name>string ( nt -- caddr u ) dup strlen ;

\ right justified output of a string in a field
: $.R ( caddr1 u1 nfield -- | assume nfield > u1)
over - spaces type ;

: word-info ( nt -- flag )
name>string
2dup cr 32 $.R \ display the word name
strpck find \ obtain the word's xt and precedence
4 spaces
1 = IF s" IMM " \ display precedence IMMEDIATE
ELSE s" "
THEN type
dup >body swap \ -- pfa xt/cfa
16 u.r \ display the xt/cfa
2 spaces
16 u.r \ display the pfa ( may not be valid )
true ;

\ Display info on each word in the specified wordlist:
\ Name, Precedence, xt/cfa, pfa
: wl-info ( wid -- )
['] word-info swap traverse-wordlist ;

hex
forth-wordlist wl-info
cr .s
----

The above should work on any Forth system which provides Forth-2012's
NAME>STRING and TRAVERSE-WORDLIST. The definition of the non-standard
word STRPCK (sometimes also called PACK) is simple. Below is the output
from "forth-wordlist wl-info", displaying information about the words in
the Forth wordlist in the traversal order, which is the same as the
search order. Notice that the body addresses at right appear to be all
over the place -- the longer ones probably correspond to EXECUTEable
bytecode sequences. A smarter >BODY should return zeros for these invalid
body addresses.

---
WL-INFO D74010 D6CF90
WORD-INFO D6CF90 D73F00
$.R D6F8F0 38000000EE74202D
NAME>STRING D73F00 D6FAE044
STRING>S D74090 0
NUMBER_VAL D73EE0 D73EC0
NUMBER_SIGN D73E50 D73DE0
S>STRING D73E70 D73CF044A2DC
STRING>D D73D70 4163A84764DC40
D>STRING D73D90 D73B404430DC
STRING>UD D73D40 4964DC4042
UD>STRING D73B40 80441B1C1864DC40
U>STRING D73CF0 4964CA40
STRPCK D73C80 FF
STRCAT D73C20 D73B8044A02BD3
STRBUFCPY D73BD0 D73B8044C9A0AA
ADJUST_STR_BUF_PTR D73B80 D6F680
STR_BUF_PTR D73B20 D6F680
STRING_BUF D6F660 D6FB10
STR_BUF_SIZE D6F7F0 D6FAC0
STRLEN D6FAE0 0
STRCPY D6F610 B8EE15CADDA0AAC9
UCASE D6FA80 6149
ISDIGIT D6FA50 30
IS_LC_ALPHA D6FA20 61
PARSE_LINE D6F9E0 0
PARSE_TOKEN D6F630 D6F98044
SKIP D6F980 4CE6F7
SCAN D6F6B0 4CE6F7
IS IMM D6F8A0 40992A47
DEFER D6F870 149
THROW D6F470 25E6
CATCH D6F830 D6F43041DC
EMPTY-HANDLER D6F450 B800000000000000
HANDLER D6F3F0 D6F430
[THEN] IMM D6F410 3800000000000000
[IF] IMM D6F5F0 12E6
[ELSE] IMM D6F720 1
$UCASE D6F500 49
F~ D6F360 46
VALUE D6AA40 149
TO IMM D6F3B0 40992A4748
PAD D6F0F0 D6F110
CHARS D6F0D0 0
SPACE D6AA20 E80000000000EE65
FTRUNC>S D46DE0 B800007FC1EEC6EE
FROUND>S D46DC0 B800007FC1EEC6EE
F>D D46DA0 B800007FC1EEC6EE
D>F D46D80 B800007FC1EEC6EE
S>F D46D60 B800007FC1EEC6EE
D>S D46D40 B800007FC1EEC6EE
S>D D46D20 B800007FC1EEC6EE
RAD>DEG D46D00 B800007FC1EEC6EE
DEG>RAD D46CE0 B800007FC1EEC6EE
FEXPM1 D46CC0 414191
FEXP D46CA0 B800007FC1EEC6EE
FLNP1 D46C80 414235

...

>FLOAT D45AC0 415F02
HOLD D45AA0 B800007FC1EEC6EE
SIGN D45A80 B800007FC1EEC6EE
#> D45A60 B800007FC1EEC6EE
#S D45A40 B800007FC1EEC6EE
# D45A20 B800007FC1EEC6EE
<# D45A00 B800007FC1EEC6EE
NUMBER? D459E0 4163A8
>NUMBER D459C0 415CA5
COUNT D459A0 B800007FC1EEC6EE
-TRAILING D45980 415744
/STRING D45960 4106A9
S" IMM D45940 B800007FC1EEC6EE
C" IMM D45920 B800007FC1EEC6EE
.( IMM D45900 B800007FC1EEC6EE
( IMM D458E0 B800007FC1EEC6EE
#! IMM D458C0 B800007FC1EEC6EE
\ IMM D458A0 B800007FC1EEC6EE
CONSOLE D45880 B800007FC1EEC6EE
>FILE D45860 B800007FC1EEC6EE
CHDIR D45840 416942
US2@ D45820 416D44
US D45800 416BC5
MS@ D457E0 B800007FC1EEC6EE
MS D457C0 B800007FC1EEC6EE
TIME&DATE D457A0 416A14
GET-ITIMER D45780 4173BC
SET-ITIMER D45760 417298

...

FIND D445C0 B800007FC1EEC6EE
WORD D445A0 B800007FC1EEC6EE
PARSE D44580 415616
ASSEMBLER D44560 40514A
VOCABULARY D44540 404E0E
PREVIOUS D44520 4050ED
ONLY D44500 404F7B
ALSO D444E0 404FAD
TRAVERSE-WORDLIST D444C0 40516B
SEARCH-WORDLIST D44280 404BC1
GET-ORDER D44260 4049E7
SET-CURRENT D44240 404992
GET-CURRENT D44220 404956
WORDLIST D44200 40488E
DEFINITIONS D441E0 404DDB
<empty>
ok

[Krishna Myneni]

On Fri, 16 Aug 2019 10:03:32 +0000, Krishna Myneni wrote:

> Well, I'm a little late to the party which I first proposed around 2012,
> and which Alex McDonald actually made happen, but better late than
> never.

...

> Reference:
>
> K. Myneni and D. N. Williams, A Forth Modules System with Name Reuse, 15
> Feb. 2012,
> https://github.com/mynenik/kForth-32/blob/master/doc/modular-forth.pdf

> ...

I did some digging on Google Groups to find references to the
discussions of TRAVERSE-WORDLIST on comp.lang.forth. Below are what I
have found, starting from the initial discussion to the RfDs and the CfV.
I don't have a link for documenting when it was actually adopted into the
Forth-2012 standard. Perhaps that may be found on forth-standard.org .

KM

---

16 Jan 2012
Title: Why no standard words for traversing a wordlist?
Author: Krishna Myneni
https://groups.google.com/d/msg/comp.lang.forth/tfatB2YH4Lg/4PknvYkClv0J

23 Jan 2012
Title: RfD: TRAVERSE-WORDLIST proposal
Author: Alex McDonald
https://groups.google.com/d/msg/comp.lang.forth/tfatB2YH4Lg/qPdajP1c2hoJ

2 April 2012
Title: strategies for implementation of USES?
Author: Krishna Myneni
https://groups.google.com/d/msg/comp.lang.forth/ElkoE7iXet8/q9vdb-gsKpYJ
(this one discusses an application of TRAVERSE-WORDLIST to make
dependency graphs)

25 July 2013
Title: RFD: TRAVERSE-WORDLIST v6 revision
Author: Alex McDonald
https://groups.google.com/d/msg/comp.lang.forth/TFGQohvSZeM/Oaubwruv9J0J

14 August 2013
Title: CfV: TRAVERSE-WORDLIST
Author: Anton Ertl
https://groups.google.com/d/msg/comp.lang.forth/pzyGv84HSAY/1CFObvpU2t8J

[dxforth]

On Friday, 16 August 2019 20:03:34 UTC+10, Krishna Myneni wrote:
> Well, I'm a little late to the party which I first proposed around 2012,
> and which Alex McDonald actually made happen, but better late than never.
> I finally got around to implementing TRAVERSE-WORDLIST in kforth64, and
> it will soon appear in kforth32. The need for this word was made apparent
> when David N. Williams and I were working on our modules framework -- the
> word is mentioned in the document modular-forth.pdf (see ref. below):

So you are to blame for this. Seven years on without having even
implemented it yourself. What does that say about need :)

[hughag...@gmail.com]

AFAIK, TRAVERSE-WORDLIST was written by Anton Ertl.
This is the only example of a HOF that the Forth-200x cult has.
Every time that the subject of quotations and HOFs comes up,
Anton Ertl trots out TRAVERSE-WORDLIST to prove that he is the
master of the subject.

[Krishna Myneni]

If you read the RfD, you will find that it was common practice in well-
known Forth systems of the time, early 2012, to implement a similar word
like this. That made it a good candidate for standardization even at that
time.

KM

[Krishna Myneni]

On Fri, 16 Aug 2019 10:03:32 +0000, Krishna Myneni wrote:

...
> \ Example of using TRAVERSE-WORDLIST: ...

Here is an exercise for Forth experts:

There is a subtle bug in my implementation of the WL-INFO example given
in my previous message, reproduced below. See if you can find the bug.

A definition of the non-standard word STRPCK used in WORD-INFO is also
given below.

---- previous example using only standard words

create name_buf 256 allot \ assume name string length < 256

: pack ( a u a2 -- | copy string to counted string at a2)
2dup c! 1+ swap cmove ;

: strpck ( caddr u -- ^name | ^name is address of counted string )
name_buf pack name_buf ;

\ right justified output of a string in a field
: $.R ( caddr1 u1 nfield -- | assume nfield > u1)
over - spaces type ;

: word-info ( nt -- flag )
name>string
2dup cr 32 $.R \ display the word name
strpck find \ obtain the word's xt and precedence
4 spaces
1 = IF s" IMM " \ display precedence IMMEDIATE
ELSE s" "
THEN type
dup >body swap \ -- pfa xt/cfa
16 u.r \ display the xt/cfa
2 spaces
16 u.r \ display the pfa ( may not be valid )
true ;

\ Display info on each word in the specified wordlist:
\ Name, Precedence, xt/cfa, pfa
: wl-info ( wid -- )
['] word-info swap traverse-wordlist ;

----

Krishna

[Anton Ertl]

Krishna Myneni <krishna...@ccreweb.org> writes:
>I did some digging on Google Groups to find references to the
>discussions of TRAVERSE-WORDLIST on comp.lang.forth. Below are what I
>have found, starting from the initial discussion to the RfDs and the CfV.
>I don't have a link for documenting when it was actually adopted into the
>Forth-2012 standard. Perhaps that may be found on forth-standard.org .

These things are found on www.forth200x.org. And there you find that
the proposal was accepted into the standard in the 2013 meeting.

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

[peter....@gmail.com]

You will have a problem if a word is redefined in the same WL.
When you have the nt of the old definition find will get the xt
of the new. You need a NT>FLAG or similar specific to your system
and skip the find part.

Peter

> ----
>
> Krishna

[Krishna Myneni]

On Sat, 17 Aug 2019 02:33:55 -0700, peter.m.falth wrote:

> On Saturday, 17 August 2019 11:02:14 UTC+2, Krishna Myneni wrote:
>> On Fri, 16 Aug 2019 10:03:32 +0000, Krishna Myneni wrote:
>>
>> ...
>> > \ Example of using TRAVERSE-WORDLIST: ...
>>
>> Here is an exercise for Forth experts:
>>
>> There is a subtle bug in my implementation of the WL-INFO example given
>> in my previous message, reproduced below. See if you can find the bug.
>>

...

> You will have a problem if a word is redefined in the same WL. When you
> have the nt of the old definition find will get the xt of the new. You
> need a NT>FLAG or similar specific to your system and skip the find
> part.
>
> Peter
>

No, there is no problem if a word is redefined in the same WL passed to
WL-INFO. The standard for TRAVERSE-WORDLIST allows for this possibility.
Each duplicate name must be visited by TRAVERSE-WORDLIST in the normal
way.

Krishna

[Krishna Myneni]

Actually, I spoke too soon without fully understanding your reply. Yes,
you are correct. FIND will always return the most recent definition. Then
the xt and precedence will not match the particular instance that is
being handled by WORD-INFO. This is definitely a big problem!

There is another problem: the wid passed to WL-INFO may not be at the top
of the search order. The word may exist in another wordlist ahead in the
search order and FIND would return it. The fix for this is to use SEARCH-
WORDLIST on the same wid passed to WL-INFO.

Sorry for my overly quick response earlier.

Krishna

[Krishna Myneni]

On Sat, 17 Aug 2019 09:42:29 +0000, Krishna Myneni wrote:

> On Sat, 17 Aug 2019 09:37:11 +0000, Krishna Myneni wrote:
>
>> On Sat, 17 Aug 2019 02:33:55 -0700, peter.m.falth wrote:
>>
>> ...
>>> You will have a problem if a word is redefined in the same WL. When
>>> you have the nt of the old definition find will get the xt of the new.
>>> You need a NT>FLAG or similar specific to your system and skip the
>>> find part.
>>>
>>> Peter
>>>

> ...
> Yes you are correct. FIND will always return the most recent definition.

> Then the xt and precedence will not match the particular instance that
> is being handled by WORD-INFO. This is definitely a big problem!
>
> There is another problem: the wid passed to WL-INFO may not be at the
> top of the search order. The word may exist in another wordlist ahead in
> the search order and FIND would return it. The fix for this is to use

> SEARCH-WORDLIST on the same wid passed to WL-INFO.

>
> Sorry for my overly quick response earlier.
>
> Krishna

The fix to the 2nd problem is given below. I believe we can use
NAME>INTERPRET from the standard to get the xt (we may also want to
display the xt for compilation semantics using NAME>COMPILE,). But I'm
not sure how we obtain the word's precedence from its nt or either of the
two possible xt's in a standard way.

Krishna

---- less buggy version (no STRPCK needed)

\ right justified output of a string in a field
: $.R ( caddr1 u1 nfield -- | assume nfield > u1)
over - spaces type ;

: word-info ( wid nt -- wid flag )
over >r \ keep a copy of the wid

name>string
2dup cr 32 $.R \ display the word name

r> search-wordlist \ obtain the word's xt and precedence

4 spaces
1 = IF s" IMM " \ display precedence IMMEDIATE
ELSE s" "
THEN type
dup >body swap \ -- pfa xt/cfa
16 u.r \ display the xt/cfa
2 spaces
16 u.r \ display the pfa ( may not be valid )
true ;

\ Display info on each word in the specified wordlist:
\ Name, Precedence, xt/cfa, pfa
: wl-info ( wid -- )

dup ['] word-info swap traverse-wordlist drop ;
----

[Anton Ertl]

Krishna Myneni <krishna...@ccreweb.org> writes:
>But I'm
>not sure how we obtain the word's precedence from its nt or either of the
>two possible xt's in a standard way.

From the nt, one can argue that the following should do the job:

: immediate? ( nt -- flag ) name>compile ['] compile, <> nip ;

This is based on the assumption that NAME>COMPILE returns the xt of
COMPILE, in TOS for non-immediate words, but that's pretty likely.
Actually, if you want FIND-based user-defined text interpreters to
work as intended, NAME>COMPILE is almost required to return the xt of
either EXECUTE (for "immediate" words), or COMPILE, (for normal words)
in TOS.

[Krishna Myneni]

On Sat, 17 Aug 2019 14:22:27 +0000, Anton Ertl wrote:

> Krishna Myneni <krishna...@ccreweb.org> writes:
>>But I'm not sure how we obtain the word's precedence from its nt or
>>either of the two possible xt's in a standard way.
>
> From the nt, one can argue that the following should do the job:
>
> : immediate? ( nt -- flag ) name>compile ['] compile, <> nip ;
>
> This is based on the assumption that NAME>COMPILE returns the xt of
> COMPILE, in TOS for non-immediate words, but that's pretty likely.
> Actually, if you want FIND-based user-defined text interpreters to work
> as intended, NAME>COMPILE is almost required to return the xt of either
> EXECUTE (for "immediate" words), or COMPILE, (for normal words)
> in TOS.
>
> - anton

Ok. I will have to test this supposition against my implementation. I
have not yet implemented NAME>COMPILE but I will check the compatibility
of this method. The precedence is an important field to be able to
access, for instance, if I want to write a word that shows me all of the
IMMEDIATE words in my search order. The standard should guarantee a way
to accomplish this.

Krishna

[Krishna Myneni]

On Sat, 17 Aug 2019 14:22:27 +0000, Anton Ertl wrote:

> Krishna Myneni <krishna...@ccreweb.org> writes:
>>But I'm not sure how we obtain the word's precedence from its nt or
>>either of the two possible xt's in a standard way.
>
> From the nt, one can argue that the following should do the job:
>
> : immediate? ( nt -- flag ) name>compile ['] compile, <> nip ;
>
> This is based on the assumption that NAME>COMPILE returns the xt of
> COMPILE, in TOS for non-immediate words, but that's pretty likely.
> Actually, if you want FIND-based user-defined text interpreters to work
> as intended, NAME>COMPILE is almost required to return the xt of either
> EXECUTE (for "immediate" words), or COMPILE, (for normal words)
> in TOS.
>
> - anton

To me "nt" really means "node token" or perhaps "word token" (wt), and
not the more limited information implied by "name token". It should point
to the address of the header information for the word's wordlist entry,
and not specifically to the name field of the header information. So the
nomenclature of "NAME>x" is a bit unfortunate. It would have been better
to call the words "NT>x" or "WT>x" to imply access to information about a
word and not just the name, although, historically, an iterated traversal
through a wordlist may have been implemented to obtain the names of
words. I can mentally translate NAME>x to meaning NT>x and then it makes
more sense that I can retrieve the word header information that is
required.

Perhaps it would be appropriate to add NAME>PRECEDENCE to the standard.
Also, given that we have "nt", shouldn't it be listed in Table 3.1 of the
Forth-2012 standards document, forth-2012.pdf?

Krishna

[dxforth]

Traversing a wordlist may be common within systems but I disagree
there was common practice or need of one. As a system implementer
I'm economically better off without TRAVERSE-WORDLIST. The case
for general users needing it has diminished as time has passed.
Being late to a 200x party is bettered only by not going at all :)

[hughag...@gmail.com]

The NT is a bad idea.
You might have an NT that you think corresponds to a particular XT,
but it doesn't. Plenty of opportunity for bugs here!

In Straight Forth I don't have an NT but only an XT.
Given the XT it is possible to read or write attributes
of the word:

IMMEDIATE@ ( xt -- flag )
WORD-LIST@ ( xt -- wid )
SMUDGE@ ( xt -- flag )
SMUDGE1@ ( xt -- flag )
SMUDGE2@ ( xt -- flag )

IMMEDIATE! ( flag xt --)
WORD-LIST! ( wid -- xt )
SMUDGE! ( flag xt -- )
SMUDGE1! ( flag xt -- )
SMUDGE2! ( flag xt -- )

[A. K.]

Some applications use wordlists as internal databases.
For them TRAVERSE-WORDLIST is fundamental.

[dxforth]

It's fundamental to embed your database application within your
compiler?

[peter....@gmail.com]

On Saturday, 17 August 2019 16:31:43 UTC+2, Anton Ertl wrote:
> Krishna Myneni <krishna...@ccreweb.org> writes:
> >But I'm
> >not sure how we obtain the word's precedence from its nt or either of the
> >two possible xt's in a standard way.
>
> From the nt, one can argue that the following should do the job:
>
> : immediate? ( nt -- flag ) name>compile ['] compile, <> nip ;
>
> This is based on the assumption that NAME>COMPILE returns the xt of
> COMPILE, in TOS for non-immediate words, but that's pretty likely.
> Actually, if you want FIND-based user-defined text interpreters to
> work as intended, NAME>COMPILE is almost required to return the xt of
> either EXECUTE (for "immediate" words), or COMPILE, (for normal words)
> in TOS.

Neither of my 2 systems return compile, or execute! They return
ht-compile, and ht-execute. ht standing for headertoken (
the nt in my systems). in both systems compile, just compiles a call
to the xt. The ht version does a lot of other things (code generation
macro expansion ).

I think it would be a mistake to limit what name>compile can return.
Just think of value/addr literal for a constant/created word for ex.

BR
Peter Fälth

[Krishna Myneni]

On Sat, 17 Aug 2019 23:33:31 -0700, A. K. wrote:

> Some applications use wordlists as internal databases.
> For them TRAVERSE-WORDLIST is fundamental.

As it stands, TRAVERSE-WORDLIST can serve as a factor for implementing
WORDS and wildcard variants of WORDS . However, it could also serve as a
factor for implementing the standard words SEARCH-WORDLIST or FIND if
there was a guaranteed way of obtaining the precedence from the node
token (nt).

Krishna

[none albert]

In article <9c3b3c5d-b158-40e2...@googlegroups.com>,

I have a tool that is a mini interpreter like c's printf.
For those who don't know printf, it takes variable data
and a string with %<name> fields where <name> represents
a format, e.g.
"AAP" 2 "two: %d animal: %s %n" .FORMAT
print
two: 2animal: AAP
OK
Those d s n are words in a separate wordlist, which you can
add to. So the answer is clear. Yes I want a database with
format's. No I don't want those single character words
mess up my Forth wordlist.

The methods of an OO-class are another example. Large, multiple
classes with many methods would give rise either to conflicts
or unwieldable names.

wordlist's and a primitive with the functionality of SEARCH-WORDLIST
are present in my 350 word ciforth, on the basis of the power they
contribute.

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

[Alex McDonald]

A key/value store is part of the language. : CREATE and so on make
entries in the database, and FIND retrieves them. So yes, there's a
database embedded in every Forth compiler.

TRAVERSE-WORDLIST enumerates them. It's in the optional
Programming-Tools word set, so you might wish to leave it away if your
economically better off without it.

--
Alex

[Alex McDonald]

On 18-Aug-19 09:09, peter....@gmail.com wrote:
> On Saturday, 17 August 2019 16:31:43 UTC+2, Anton Ertl wrote:
>> Krishna Myneni <krishna...@ccreweb.org> writes:
>>> But I'm
>>> not sure how we obtain the word's precedence from its nt or either of the
>>> two possible xt's in a standard way.
>>
>> From the nt, one can argue that the following should do the job:
>>
>> : immediate? ( nt -- flag ) name>compile ['] compile, <> nip ;
>>
>> This is based on the assumption that NAME>COMPILE returns the xt of
>> COMPILE, in TOS for non-immediate words, but that's pretty likely.
>> Actually, if you want FIND-based user-defined text interpreters to
>> work as intended, NAME>COMPILE is almost required to return the xt of
>> either EXECUTE (for "immediate" words), or COMPILE, (for normal words)
>> in TOS.
>
> Neither of my 2 systems return compile, or execute! They return
> ht-compile, and ht-execute. ht standing for headertoken (
> the nt in my systems). in both systems compile, just compiles a call
> to the xt. The ht version does a lot of other things (code generation
> macro expansion ).
>
> I think it would be a mistake to limit what name>compile can return.
> Just think of value/addr literal for a constant/created word for ex.

Anton mentions "almost" being forced to return EXECUTE or COMPILE, but
that leads to a smart COMPILE, to cope with the likes of S" which does
not have standard compilation semantics.

Mine returns EXECUTE COMPILE, and NDCS-COMP (for non-default compilation
semantics words). I'm not particularly interested in supporting a FIND
based text interpreter.


--
Alex

[Anton Ertl]

Krishna Myneni <krishna...@ccreweb.org> writes:
>To me "nt" really means "node token" or perhaps "word token" (wt), and
>not the more limited information implied by "name token". It should point
>to the address of the header information for the word's wordlist entry,
>and not specifically to the name field of the header information.

Nothing says that it points to the name field. The "name" in "name
token" refers to the fact that it refers to a named word, in contrast
to nameless words (e.g., produced by :NONAME), which have an xt, but
not necessarily an nt.

[bikeshedding snipped]

>Perhaps it would be appropriate to add NAME>PRECEDENCE to the standard.
>Also, given that we have "nt", shouldn't it be listed in Table 3.1 of the
>Forth-2012 standards document, forth-2012.pdf?

It is. See 15.3.1. Whether it makes sense to extend Table 3.1
piecewise with each wordset, or whether it would be better to just
have it all in one place is something we might want to discuss.

[Anton Ertl]

peter....@gmail.com writes:
>On Saturday, 17 August 2019 16:31:43 UTC+2, Anton Ertl wrote:
>> : immediate? ( nt -- flag ) name>compile ['] compile, <> nip ;

>>=20

>> This is based on the assumption that NAME>COMPILE returns the xt of
>> COMPILE, in TOS for non-immediate words, but that's pretty likely.
>> Actually, if you want FIND-based user-defined text interpreters to
>> work as intended, NAME>COMPILE is almost required to return the xt of
>> either EXECUTE (for "immediate" words), or COMPILE, (for normal words)
>> in TOS.
>
>Neither of my 2 systems return compile, or execute! They return
>ht-compile, and ht-execute. ht standing for headertoken (
>the nt in my systems). in both systems compile, just compiles a call
>to the xt. The ht version does a lot of other things (code generation
>macro expansion ).

In that case, IMMEDIATE? would have to be defined as, e.g.:

: immediate? ( nt -- flag ) name>compile ['] ht-compile, <> nip ;

The question is: What does FIND return? Does a user-defined text
interpreter along the lines of the following work as intended?

(from <http://forth-standard.org/standard/core/COMPILEComma>):
|... ( c-addr )
|FIND ?DUP IF ( xt +-1 )
| STATE @ IF ( xt +-1 )
| 0> IF EXECUTE ELSE COMPILE, THEN ( ??? )
| ELSE ( xt +-1 )
| DROP EXECUTE ( ??? )
| THEN
|ELSE ( c-addr )
| ( whatever you do for an undefined word )
|THEN
|...

It is possible to define NAME>COMPILE in the way you indicate above,
and still have a FIND where such user-defined text interpreter work;
FIND just has to convert the nt to an xt, and produce an appropriate
1/-1 value.

>I think it would be a mistake to limit what name>compile can return.

Once you eliminate FIND, it's unlimited. But as long as we implement
FIND, NAME>COMPILE can only do things that you can also represent
through the FIND interface; using the FIND interface and COMPILE, may
result in worse code, though.

>Just think of value/addr literal for a constant/created word for ex.

Yes, that's a possibility, and in the early days of NAME>COMP I
thought that we would use such things. These days, however, the
intelligent COMPILE, compiles constants and created words to literals.

[Anton Ertl]

Or you can just implement FIND-NAME-IN and FIND-NAME. However, the
system's implementations of all these words usually are much faster
because they employ techniques like hash table lookup to find the
desired name faster than through linear search.

I am not convinced that a word like IMMEDIATE? ( nt -- f ) is useful.

For your wordinfo project, why not just print (ideally in a readable
form) what NAME>COMPILE and NAME>INTERPRET return?

[Anton Ertl]

Alex McDonald <al...@rivadpm.com> writes:
>Anton mentions "almost" being forced to return EXECUTE or COMPILE, but
>that leads to a smart COMPILE, to cope with the likes of S" which does
>not have standard compilation semantics.

It does not (and perverting COMPILE, in that way would be wrong).
Here you can see how it can work with just EXECUTE and COMPILE,:

\ let's redefine S" with named components (they are unnamed in
\ Gforth, but the code is otherwise the same)
: s"-int '"' parse save-mem ;
: s"-comp '"' parse postpone sliteral ;
' s"-int ' s"-comp interpret/compile: s"

\ now show the xts produced by NAME>INTERPRET and NAME>COMPILE for S"
(') s" name>interpret ... drop \ prints "<1> `s"-int"
(') s" name>compile ... 2drop \ prints "<2> `s"-comp `execute"

As you can see, no need to pervert COMPILE, to deal with S".

[Krishna Myneni]

On Sun, 18 Aug 2019 14:37:18 +0000, Anton Ertl wrote:

> Krishna Myneni <krishna...@ccreweb.org> writes:

...
>
> [bikeshedding snipped]
>
...
> - anton

I'm generally in concurrence with the rest of your reply, so I will
address this point. Frankly, I'm surprised someone from a technical
academic background would find a discussion of precision in language, in
the naming of words, to be trivial details. In fact there is quite a bit
of cost resulting from use of imprecise language. For instance, you point
out that "nt" really stands for "named-word token", although it has been
referred to as "name token". The former description is more precise while
the latter is ambiguous -- it can be interpreted as the name field of a
word header, and, in fact, I did interpret it like this in my first
implementation of TRAVERSE-WORDLIST (commit 269a933 for kForth-64 project
on GitHub):

----
int CPP_traverse_wordlist()
{
// Forth 2012 Tools Wordset: 15.6.2.2297
// stack: ( i*x xt wid -- j*x | execute xt for every word in wordlist)
// Execution of xt has stack effect ( k*x nt -- l*x flag )

DROP
CHK_ADDR
WordList* pWL = (WordList*) TOS;
DROP
CHK_ADDR
unsigned char* cfa = (unsigned char*) TOS; // xt is same as cfa
WordIndex i;
int e;
if (pWL->size()) {
for (i = pWL->end()-1; i >= pWL->begin(); --i) {
TOS = (long int) i->WordName;
DEC_DSP
STD_ADDR
e = vm(cfa);
DROP
long int b = (long int) TOS;
if (b == 0) break;
}
}
return 0;
}
----

The line "TOS = (long int) i->WordName;" fetches the name field of the
word header.

Had the description of "nt" in the standards document said, "named-word
token", instead of "name token", it might have saved me a good bit of
time and effort to arrive at the current implementation:

----
int CPP_traverse_wordlist()
{
// Forth 2012 Tools Wordset: 15.6.2.2297
// stack: ( i*x xt wid -- j*x | execute xt for every word in
wordlist)
// Execution of xt has stack effect ( k*x nt -- l*x flag )

DROP
CHK_ADDR
WordList* pWL = (WordList*) TOS;
DROP
CHK_ADDR
unsigned char* cfa = (unsigned char*) TOS; // xt is same as cfa
WordIndex i;
WordListEntry *w;
int e;
if (pWL->size()) {
for (i = pWL->end()-1; i >= pWL->begin(); --i) {
w = *((WordListEntry**) &i); // this is the node token, nt
TOS = (long int) w;
DEC_DSP
STD_ADDR
e = vm(cfa);
DROP
long int b = (long int) TOS;
if (b == 0) break;
}
}
return e;
}
----

The line, "TOS = (long int) w;", now returns the "named-word token"
rather than the name field of the word token.

A far worse side effect is that I propagated the poor choice of original
implementation for TRAVERSE-WORDLIST due to language imprecision in the
standard in a posting on c.l.f. providing an example of implementing
NAME>STRING as

: NAME>STRING ( nt -- c-addr u ) dup strlen ;

I have since fixed this by re-implementing NAME>STRING to work with the
"named-word token".

There are costs to imprecision and ambiguity in wording.

Krishna

[peter....@gmail.com]

On Sunday, 18 August 2019 17:33:48 UTC+2, Anton Ertl wrote:
> peter....@gmail.com writes:
> >On Saturday, 17 August 2019 16:31:43 UTC+2, Anton Ertl wrote:
> >> : immediate? ( nt -- flag ) name>compile ['] compile, <> nip ;
> >>=20
> >> This is based on the assumption that NAME>COMPILE returns the xt of
> >> COMPILE, in TOS for non-immediate words, but that's pretty likely.
> >> Actually, if you want FIND-based user-defined text interpreters to
> >> work as intended, NAME>COMPILE is almost required to return the xt of
> >> either EXECUTE (for "immediate" words), or COMPILE, (for normal words)
> >> in TOS.
> >
> >Neither of my 2 systems return compile, or execute! They return
> >ht-compile, and ht-execute. ht standing for headertoken (
> >the nt in my systems). in both systems compile, just compiles a call
> >to the xt. The ht version does a lot of other things (code generation
> >macro expansion ).
>
> In that case, IMMEDIATE? would have to be defined as, e.g.:
>
> : immediate? ( nt -- flag ) name>compile ['] ht-compile, <> nip ;

That will work on my 64 bit system but not on the old 32 bit.
The old system returns ht-compile, for all words and when executed
do the right thing also for immediate words. It was a component long
before name>compile were invented. Instead the right solution is

: immediate? ( nt -- flag ) ht>flag c@ 8 = ;

Of course that is specific to my system but so is ht-compile, also.

>
> The question is: What does FIND return? Does a user-defined text
> interpreter along the lines of the following work as intended?
>
> (from <http://forth-standard.org/standard/core/COMPILEComma>):
> |... ( c-addr )
> |FIND ?DUP IF ( xt +-1 )
> | STATE @ IF ( xt +-1 )
> | 0> IF EXECUTE ELSE COMPILE, THEN ( ??? )
> | ELSE ( xt +-1 )
> | DROP EXECUTE ( ??? )
> | THEN
> |ELSE ( c-addr )
> | ( whatever you do for an undefined word )
> |THEN
> |...

This will work on my 64 bit system but produce less efficient code.
It will not work on my old system as find only returns the
interpretation xt

> It is possible to define NAME>COMPILE in the way you indicate above,
> and still have a FIND where such user-defined text interpreter work;
> FIND just has to convert the nt to an xt, and produce an appropriate
> 1/-1 value.
>
> >I think it would be a mistake to limit what name>compile can return.
>
> Once you eliminate FIND, it's unlimited. But as long as we implement
> FIND, NAME>COMPILE can only do things that you can also represent
> through the FIND interface; using the FIND interface and COMPILE, may
> result in worse code, though.

I gave up on FIND over 20 years ago!
I now have find-interpret and find-compile

>
> >Just think of value/addr literal for a constant/created word for ex.
>
> Yes, that's a possibility, and in the early days of NAME>COMP I
> thought that we would use such things. These days, however, the
> intelligent COMPILE, compiles constants and created words to literals.

I like my dumb COMPILE, that only compiles a call to the xt.
It is simple and predictable.

Peter Fälth

[Alex McDonald]

On 18-Aug-19 18:23, Krishna Myneni wrote:
> On Sun, 18 Aug 2019 14:37:18 +0000, Anton Ertl wrote:
>
>> Krishna Myneni <krishna...@ccreweb.org> writes:
> ...
>>
>> [bikeshedding snipped]
>>
> ...
>> - anton
>
> I'm generally in concurrence with the rest of your reply, so I will
> address this point. Frankly, I'm surprised someone from a technical
> academic background would find a discussion of precision in language, in
> the naming of words, to be trivial details. In fact there is quite a bit
> of cost resulting from use of imprecise language.

This word "bikeshedding" annoys me immensely.

For instance, the recognizer proposal has the word RECTYPE-NULL to which
I objected; the value is not a null in any traditional sense (it is the
address of a 3 cell structure), and RECTYPE as shorthand for RECognized
TYPE is a bit of a stretch, as it more commonly means RECord TYPE.

I proposed UNRECOGNIZED, but got back 0 CONSTANT BIKESHEDDING in reply.

Language is important, even in the early stages of a proposal.


--
Alex

[Krishna Myneni]

On Sun, 18 Aug 2019 21:47:12 +0100, Alex McDonald wrote:

> On 18-Aug-19 18:23, Krishna Myneni wrote:
>> On Sun, 18 Aug 2019 14:37:18 +0000, Anton Ertl wrote:
>>
>>> Krishna Myneni <krishna...@ccreweb.org> writes:
>> ...
>>>
>>> [bikeshedding snipped]
>>>
>> ...
>>> - anton
>>

>> ... In fact there is quite a

>> bit of cost resulting from use of imprecise language.
>
> This word "bikeshedding" annoys me immensely.
>

> ...

> I proposed UNRECOGNIZED, but got back 0 CONSTANT BIKESHEDDING in reply.
>
> Language is important, even in the early stages of a proposal.

Using a pejorative dismissal doesn't do much to advance the discussion.
It means the person doing the dismissing isn't comfortable talking about
that topic or doesn't want to deal with it. Fine, then they should just
not respond to it.

KM

[Krishna Myneni]

On Sun, 18 Aug 2019 15:34:17 +0000, Anton Ertl wrote:

> Krishna Myneni <krishna...@ccreweb.org> writes:
>>On Sat, 17 Aug 2019 23:33:31 -0700, A. K. wrote:
>>
>>> Some applications use wordlists as internal databases.
>>> For them TRAVERSE-WORDLIST is fundamental.
>>
>>As it stands, TRAVERSE-WORDLIST can serve as a factor for implementing
>>WORDS and wildcard variants of WORDS . However, it could also serve as a
>>factor for implementing the standard words SEARCH-WORDLIST or FIND if
>>there was a guaranteed way of obtaining the precedence from the node
>>token (nt).
>

...

>
> I am not convinced that a word like IMMEDIATE? ( nt -- f ) is useful.
>

Do you mean it is not generally useful from a standards perspective?
Obviously I have a specific use for it.

> For your wordinfo project, why not just print (ideally in a readable
> form) what NAME>COMPILE and NAME>INTERPRET return?

I had not yet implemented NAME>COMPILE and NAME>INTERPRET and I thought
FIND was a way to do it. But this turned out to be wrong for at least two
reasons:

1) FIND cannot be used to return the xt and precedence for redefinitions
within a wordlist.

2) FIND will only return the first definition's xt and precedence in the
first wordlist of the search order, which may not be the wordlist passed
to WL-INFO.

The NAME>COMPILE and NAME>INTERPRET techniques are the best way to obtain
the xt (from which the body address can be retrieved). It's not clear to
me yet that the precedence can be retrieved in this way, but I will try
your suggestion.

Incidentally, the output of WL-INFO is in formatted readable form, but
Google Groups mangles it with proportional spacing, and perhaps your
newsgroup reader also breaks the lines. Try running it from Gforth in a
terminal.

KM

[dxforth]

On Sunday, 18 August 2019 23:38:28 UTC+10, Alex McDonald wrote:
> On 18-Aug-19 09:02, dxforth wrote:
> > On Sunday, 18 August 2019 16:33:33 UTC+10, A. K. wrote:

> >> ...

> >> Some applications use wordlists as internal databases.
> >> For them TRAVERSE-WORDLIST is fundamental.
> >
> > It's fundamental to embed your database application within your
> > compiler?
> >
>
> A key/value store is part of the language. : CREATE and so on make
> entries in the database, and FIND retrieves them. So yes, there's a
> database embedded in every Forth compiler.

It's mumbo-jumbo used to justify the absence of leadership in Forth.
If you aren't using it everyday, it's not Forth. It's that simple.
If the truth of the thing you wish to promote is not immediately
obvious to all, it's not simple and it's not Forth. If one has to
invent acronyms e.g. NDCS one can be assured it's not Forth and
simply mumbo-jumbo used to fool yourself or others. The world OTOH
is not so easily fooled.

[Anton Ertl]

Krishna Myneni <krishna...@ccreweb.org> writes:
>On Sun, 18 Aug 2019 15:34:17 +0000, Anton Ertl wrote:
>> I am not convinced that a word like IMMEDIATE? ( nt -- f ) is useful.
>>
>
>Do you mean it is not generally useful from a standards perspective?

Yes. Since Forth-94, Forth words have interpretation and compilation
semantics, and IMMEDIATE is just a way to modify compilation
semantics. So whatever IMMEDIATE does to a word is reflected in the
result of NAME>COMPILE, so IMMEDIATE? is unnecessary.

>Obviously I have a specific use for it.

And we have, too, otherwise it would not be in Gforth. We use it as a
helper for implementing SEE.

[Anton Ertl]

Alex McDonald <al...@rivadpm.com> writes:
>On 18-Aug-19 18:23, Krishna Myneni wrote:
>> On Sun, 18 Aug 2019 14:37:18 +0000, Anton Ertl wrote:
>>
>>> Krishna Myneni <krishna...@ccreweb.org> writes:
>> ...
>>>
>>> [bikeshedding snipped]
>>>
>> ...
>>> - anton
>>
>> I'm generally in concurrence with the rest of your reply, so I will
>> address this point. Frankly, I'm surprised someone from a technical
>> academic background would find a discussion of precision in language, in
>> the naming of words, to be trivial details. In fact there is quite a bit
>> of cost resulting from use of imprecise language.

True. Nevertheless, discussions about word names are both very popular
and usually unproductive. They are especially unproductive 6 years
after the words have been accepted into the standard. Apparently
enough people found the names NAME>INTERPRET, NAME>COMPILE and
NAME>STRING acceptable. They are not going to change. Learn to live
with them.

>This word "bikeshedding" annoys me immensely.

The activity of bikeshedding annoys me immensely. Instead of
discussing-tuning the rest of the proposal, most the participants and
an even larger part of the postings concern themselves exclusively
with word names. And what's worse, everybody just proposes their own
better name, and rarely is anybody convincing anybody else to agree on
a common name.

>For instance, the recognizer proposal has the word RECTYPE-NULL to which
>I objected; the value is not a null in any traditional sense (it is the
>address of a 3 cell structure), and RECTYPE as shorthand for RECognized
>TYPE is a bit of a stretch, as it more commonly means RECord TYPE.
>
>I proposed UNRECOGNIZED, but got back 0 CONSTANT BIKESHEDDING in reply.
>
>Language is important, even in the early stages of a proposal.

Sometime during the proposal stage there is a time for deciding about
word names. I don't think that time is in the early stages, because
then we actually don't have nailed down the behaviour of the words, so
some groups of words could be replaced with other groups of words.
Using mnemonic names (even if suboptimal for almost everybody) at that
time instead of X1 X2 X3 is still useful to make it easier to
understand the proposal.

But any discussion about word names early in the proposal stage
detracts from discussing the rest of the proposal. So once the rest
has been mostly settled, is the time for deciding about word names.

In some of my proposals, I have taken straw polls about the preferred
name(s) at some point, and then incorporated the one(s) that got most
votes.

Once the word names have been settled in this way, any further
discussion about word names is a waste of time.

In the case of the recognizer proposal, the Forth200x committee
managed to channel the name discussion into one session, and in that
session (where, following the usual pattern, more people expressed an
opinion than about the rest of the proposal), the committee agreed on
new names for many of the words in the proposal. Matthias Trute
dutifully incorporated these names into his proposal. So if you want
different names, you would have to convince the committee to suggest
yet another name change to Matthias Trute. It's not too late (unlike
for NAME>STRING etc.), but it won't be easy.

[Anton Ertl]

Krishna Myneni <krishna...@ccreweb.org> writes:
>Using a pejorative dismissal doesn't do much to advance the discussion.

Discussing word names does not do anything to advance the discussion.
That's because almost everybody has a suggestion for a "better" name
(no matter what name is proposed).

For words that were accepted into the standard 6 years ago, discussing
the names is definitely not going to advance the discussion.

>It means the person doing the dismissing isn't comfortable talking about
>that topic or doesn't want to deal with it.

Correct, I think that discussing the names of already standardized
words is a waste of time, because they are not going to change (and
most of the discussions about the topic before standardization are
also a waste of time). Mentioning "bikeshedding" was intended as a
hint that you should not waste your and our time with this stuff.
Maybe "crying over spilt milk" or "that ship has sailed" would have
been better understood. "Bikeshedding" also applies to the case
before standardization.

[Alex McDonald]

On 19-Aug-19 00:46, dxforth wrote:
> On Sunday, 18 August 2019 23:38:28 UTC+10, Alex McDonald wrote:
>> On 18-Aug-19 09:02, dxforth wrote:
>>> On Sunday, 18 August 2019 16:33:33 UTC+10, A. K. wrote:
>>>> ...
>>>> Some applications use wordlists as internal databases.
>>>> For them TRAVERSE-WORDLIST is fundamental.
>>>
>>> It's fundamental to embed your database application within your
>>> compiler?
>>>
>>
>> A key/value store is part of the language. : CREATE and so on make
>> entries in the database, and FIND retrieves them. So yes, there's a
>> database embedded in every Forth compiler.
>
> It's mumbo-jumbo used to justify the absence of leadership in Forth.

I don't have a clue what that has to do with my answer.

> If you aren't using it everyday, it's not Forth. It's that simple.
> If the truth of the thing you wish to promote is not immediately
> obvious to all, it's not simple and it's not Forth. If one has to
> invent acronyms e.g. NDCS one can be assured it's not Forth and
> simply mumbo-jumbo used to fool yourself or others. The world OTOH
> is not so easily fooled.
>

Well, I do use TRAVERSE-WORDLIST every day of the week, in the form of
WORDS for one, and in some experimental editing tools that I'm
developing that provide word completion while typing.

Acronyms and abbreviations are shorthand, and even you are susceptible
to their charms; look at that e.g. right next to NDCS. I suppose NDCS
could be spelled out, but then I suppose you'd complain that you don't
want to talk about non-default compilation semantics in the absence of
Forth leadership that you approve of.

This approach is lose-lose for everyone.

--
Alex

[Alex McDonald]

On 18-Aug-19 16:48, Anton Ertl wrote:
> Alex McDonald <al...@rivadpm.com> writes:
>> Anton mentions "almost" being forced to return EXECUTE or COMPILE, but
>> that leads to a smart COMPILE, to cope with the likes of S" which does
>> not have standard compilation semantics.
>
> It does not (and perverting COMPILE, in that way would be wrong).
> Here you can see how it can work with just EXECUTE and COMPILE,:
>
> \ let's redefine S" with named components (they are unnamed in
> \ Gforth, but the code is otherwise the same)
> : s"-int '"' parse save-mem ;
> : s"-comp '"' parse postpone sliteral ;
> ' s"-int ' s"-comp interpret/compile: s"
>
> \ now show the xts produced by NAME>INTERPRET and NAME>COMPILE for S"
> (') s" name>interpret ... drop \ prints "<1> `s"-int"
> (') s" name>compile ... 2drop \ prints "<2> `s"-comp `execute"
>
> As you can see, no need to pervert COMPILE, to deal with S".
>
> - anton
>

But that's not how the standard text interpreter works, because it
doesn't use FIND-NAME or NAME>xxx words. To support NDCS we have

1. FIND returns an XT based on STATE.
2. Compromised COMPILE,
3. IMMEDIATE STATE-smart words

All these have been tried. All these have significant issues, and
there's not yet consensus on a "#4 Fix the problem with...".

--
Alex

[Krishna Myneni]

On Mon, 19 Aug 2019 07:16:09 +0000, Anton Ertl wrote:

> Alex McDonald <al...@rivadpm.com> writes:
>>On 18-Aug-19 18:23, Krishna Myneni wrote:
>>> On Sun, 18 Aug 2019 14:37:18 +0000, Anton Ertl wrote:
>>>
>>>> Krishna Myneni <krishna...@ccreweb.org> writes:
>>> ...
>>>>
>>>> [bikeshedding snipped]
>>>>
>>> ...
>>>> - anton
>>>
>>> I'm generally in concurrence with the rest of your reply, so I will
>>> address this point. Frankly, I'm surprised someone from a technical
>>> academic background would find a discussion of precision in language,
>>> in the naming of words, to be trivial details. In fact there is quite
>>> a bit of cost resulting from use of imprecise language.
>
> True. Nevertheless, discussions about word names are both very popular
> and usually unproductive. They are especially unproductive 6 years
> after the words have been accepted into the standard. Apparently enough
> people found the names NAME>INTERPRET, NAME>COMPILE and NAME>STRING
> acceptable. They are not going to change. Learn to live with them.
>

You missed my point. While I might have ruminated about word names I
thought might have been more descriptive, I made no suggestion to change
them. The real point was, what does "nt" stand for. It became clear only
when you stated that it is to be interpreted as an abbreviation for
"named-word token" rather than "name token". Table 15.1 of the Forth-2012
standards document refers to "nt" as a "name token". It is the
imprecision in language here that is the source of the problem. This is
what needs to be changed, in my opinion.

KM

[none albert]

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

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>Krishna Myneni <krishna...@ccreweb.org> writes:
>>To me "nt" really means "node token" or perhaps "word token" (wt), and
>>not the more limited information implied by "name token". It should point
>>to the address of the header information for the word's wordlist entry,
>>and not specifically to the name field of the header information.
>
>Nothing says that it points to the name field. The "name" in "name
>token" refers to the fact that it refers to a named word, in contrast
>to nameless words (e.g., produced by :NONAME), which have an xt, but
>not necessarily an nt.

I've now for a long time tried to introduce dea, dictionary entry
address, for a token that identifies a Forth word and find
all its properties. To no avail. I use it in my own documentation
in ciforth's and tforth (AC 23).

It is kind of bizar to have a "name token", then use it to change
the name of a word. With a dea, not so much.

>
>- anton

[Alex McDonald]

On 19-Aug-19 12:06, albert wrote:
> In article <2019Aug1...@mips.complang.tuwien.ac.at>,
> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>> Krishna Myneni <krishna...@ccreweb.org> writes:
>>> To me "nt" really means "node token" or perhaps "word token" (wt), and
>>> not the more limited information implied by "name token". It should point
>>> to the address of the header information for the word's wordlist entry,
>>> and not specifically to the name field of the header information.
>>
>> Nothing says that it points to the name field. The "name" in "name
>> token" refers to the fact that it refers to a named word, in contrast
>> to nameless words (e.g., produced by :NONAME), which have an xt, but
>> not necessarily an nt.
>
> I've now for a long time tried to introduce dea, dictionary entry
> address, for a token that identifies a Forth word and find
> all its properties. To no avail. I use it in my own documentation
> in ciforth's and tforth (AC 23).

My objection would be twofold.

First, to the word "address". It doesn't need to be; it's meant to be an
opaque value, a name /token/. The same is true of "execution /token/"
where the token doesn't need to be an address either.

Second, to the phrase dictionary entry. I use the definition of
dictionary in CS terms i.e. "Any data structure representing a set of
elements that can support the insertion and deletion of elements as well
as a test for membership." Forth wordlists don't support deletion*, and
although a wordlist can be constructed from a dictionary, they are not
dictionaries.

*Smudging is not standard.

>
> It is kind of bizar to have a "name token", then use it to change
> the name of a word. With a dea, not so much.

The name token concept doesn't support changing the name.

Names of words are important, even at the early stages of discussion. I
don't subscribe to Anton's position; I believe that the name of a thing
often delineates its capabilities in the mind of the reader. QV DEA.


--
Alex

[Alex McDonald]

On 19-Aug-19 08:16, Anton Ertl wrote:
> Alex McDonald <al...@rivadpm.com> writes:

>>

>> Language is important, even in the early stages of a proposal.
>
> Sometime during the proposal stage there is a time for deciding about
> word names. I don't think that time is in the early stages, because
> then we actually don't have nailed down the behaviour of the words, so
> some groups of words could be replaced with other groups of words.
> Using mnemonic names (even if suboptimal for almost everybody) at that
> time instead of X1 X2 X3 is still useful to make it easier to
> understand the proposal.
>
> But any discussion about word names early in the proposal stage
> detracts from discussing the rest of the proposal. So once the rest
> has been mostly settled, is the time for deciding about word names.

Too late. And as you note below, it is never easy to change at that
stage, otherwise we wouldn't be having this conversation.

>
> In some of my proposals, I have taken straw polls about the preferred
> name(s) at some point, and then incorporated the one(s) that got most
> votes.
>
> Once the word names have been settled in this way, any further
> discussion about word names is a waste of time.
>
> In the case of the recognizer proposal, the Forth200x committee
> managed to channel the name discussion into one session, and in that
> session (where, following the usual pattern, more people expressed an
> opinion than about the rest of the proposal),

That perhaps says more to support my position. I presume they're not all
idiots.

> the committee agreed on
> new names for many of the words in the proposal. Matthias Trute
> dutifully incorporated these names into his proposal. So if you want
> different names, you would have to convince the committee to suggest
> yet another name change to Matthias Trute. It's not too late (unlike
> for NAME>STRING etc.), but it won't be easy.

I don't agree with this at all. Names are incredibly important; as I
point out to Albert elsewhere, calling something a "dictionary entry
address" is so specific as to rule out in the reader's mind anything
other than dictionaries, linear entries, & addresses.

IMHO (and this is an attempt to be humble, since you guys are paying to
do the legwork here):

The committee needs to consider names far more carefully at the proposal
stage than perhaps it is; for instance, if ATTENUATE-FRAMISTAN
C-MUMBLE-BLETCH and TOKENIZE-MY-ASS (George Shaw's bikeshedding
observation about Mitch Bradley's proposed names for inclusion in ANS
Forth) had been proposed to facilitate discussion, I'm sure quite a few
on the committee would have had a George Shaw moment. RECTYPE-NULL makes
me feel the same way.

--
Alex

[Alex McDonald]

On 18-Aug-19 16:34, Anton Ertl wrote:
> Or you can just implement FIND-NAME-IN and FIND-NAME.

There's a proposal under
http://forth-standard.org/standard/core/FIND#contribution-58. Is that
the authoritative RfD?

--
Alex

[Anton Ertl]

Alex McDonald <al...@rivadpm.com> writes:
>On 18-Aug-19 16:48, Anton Ertl wrote:
>> Alex McDonald <al...@rivadpm.com> writes:
>>> Anton mentions "almost" being forced to return EXECUTE or COMPILE, but
>>> that leads to a smart COMPILE, to cope with the likes of S" which does
>>> not have standard compilation semantics.
>>
>> It does not (and perverting COMPILE, in that way would be wrong).
>> Here you can see how it can work with just EXECUTE and COMPILE,:
>>
>> \ let's redefine S" with named components (they are unnamed in
>> \ Gforth, but the code is otherwise the same)
>> : s"-int '"' parse save-mem ;
>> : s"-comp '"' parse postpone sliteral ;
>> ' s"-int ' s"-comp interpret/compile: s"
>>
>> \ now show the xts produced by NAME>INTERPRET and NAME>COMPILE for S"
>> (') s" name>interpret ... drop \ prints "<1> `s"-int"
>> (') s" name>compile ... 2drop \ prints "<2> `s"-comp `execute"
>>
>> As you can see, no need to pervert COMPILE, to deal with S".
>>
>> - anton
>>
>
>
>But that's not how the standard text interpreter works, because it
>doesn't use FIND-NAME or NAME>xxx words.

I assume you mean the classic user-defined text interpreter.

> To support NDCS we have
>
>1. FIND returns an XT based on STATE.

That's what Forth-94 suggests, what cmForth does, and what Gforth
does.

>2. Compromised COMPILE,

That's non-standard, or, as you write, compromised.

>3. IMMEDIATE STATE-smart words

The Forth-94 committee probably intended that S" could be implemented
in that way, but they guaranteed too much to allow that. The
Forth200x committee occasionally discussed fixing that, but obviously
none of us considered it important enough to write a proposal for that
fix.

>All these have been tried. All these have significant issues,

What are the "significant issues" of variant #1?

>and
>there's not yet consensus on a "#4 Fix the problem with...".

I am not even aware that #4 exists, apart from not supporting the
FIND-based user-defined text interpreter (which is not guaranteed in
Forth-94 nor Forth-2012). But if we want to support it, the options
are limited. Consider it (from
<http://forth-standard.org/standard/rationale#rat:core:COMPILE,>)

|... ( c-addr )
|FIND ?DUP IF ( xt +-1 )
| STATE @ IF ( xt +-1 )
| 0> IF EXECUTE ELSE COMPILE, THEN ( ??? )
| ELSE ( xt +-1 )
| DROP EXECUTE ( ??? )
| THEN
|ELSE ( c-addr )
| ( whatever you do for an undefined word )
|THEN
|...

So where do we separate the two different behaviours of S" ?

If FIND returns different xts based on STATE, this results in #1.

If FIND returns a single xt and 1 for S", the word is EXECUTEd in
either state, so the behaviours have to be separated during that
execution, leading to STATE-smart words (#3). Problem: Also
STATE-smart when POSTPONEd and ticked (unless one special-cases S" in
', ['], POSTPONE, etc. This is the way to make STATE-smart
implementations of S" standard, but AFAIK nobody uses it).

If FIND returns a single xt and -1, the xt is COMPILE,d in compile
state and EXECUTEd in interpret state, which inspires the idea of
defining COMPILE, of the xt of S" to perform the compilation semantics
of S", while EXECUTEing the same xt performs the interpretation
semantics (#2). Problem: COMPILE, is not documented as parsing (the
compilation semantics of S" parses), and, more importantly, has to be
equivalent to

: compile, postpone literal postpone execute ;

There is quite a bit of code that relies an this equivalence (probably
every use of COMPILE, that is not part of a text interpreter).

[Anton Ertl]

Krishna Myneni <krishna...@ccreweb.org> writes:
>The real point was, what does "nt" stand for. It became clear only
>when you stated that it is to be interpreted as an abbreviation for
>"named-word token" rather than "name token". Table 15.1 of the Forth-2012
>standards document refers to "nt" as a "name token".

Maybe, if you read the document a little more closely, you find the
sentence right above Table 15.1, which says:

|A name token is a single-cell value that identifies a named word.

>It is the
>imprecision in language here that is the source of the problem. This is
>what needs to be changed, in my opinion.

Wording changes are easier. You can make a proposal, and see if it
gets support.

[Anton Ertl]

Alex McDonald <al...@rivadpm.com> writes:
>Second, to the phrase dictionary entry. I use the definition of
>dictionary in CS terms i.e. "Any data structure representing a set of
>elements that can support the insertion and deletion of elements as well
>as a test for membership."

I am sure that Albert used the Forth meaning, which is more
appropriate here.

The standard says (2.1):

|dictionary:
|
|An extensible structure that contains definitions and associated data space.

"Dictionary entry" is completely understandable to me, even though it
is not a term in common usage in Forth. "(Word) header" is more
common, and Gforth has >HEAD as alias for >NAME, but we eventually
settled on the NAME convention.

>Names of words are important, even at the early stages of discussion. I
>don't subscribe to Anton's position; I believe that the name of a thing
>often delineates its capabilities in the mind of the reader. QV DEA.

Counterevidence: Albert van der Horst has noticed that dea and nt are
essentially the same thing despite the difference in names. People
often react to a proposal or the publication of a program by
suggesting additional capabilities, sometimes against the intent of
the author.

It may happen that the name misleads the reader, but I think that this
effect is most pronounced on superficial reading, and vanishes for
people who explore a proposal in depth.

And while a better terminology or better names may be better, a
discussion about terminology or names is usually distracting and thus
worse.

[Alex McDonald]

On 19-Aug-19 17:49, Anton Ertl wrote:

>
> It may happen that the name misleads the reader, but I think that this
> effect is most pronounced on superficial reading, and vanishes for
> people who explore a proposal in depth.

Sigh. I really do wish that you wouldn't do this. I've read the proposal
several times, in detail, and understand exactly what each words means
and does. And a few of them have names that don't describe what they are
or do, which is quite remarkable considering that a well qualified group
sat round the back of the bikeshed, and proposed, discussed and then
chose them.

>
> And while a better terminology or better names may be better, a

Ah, light.

> discussion about terminology or names is usually distracting and thus
> worse.

Sighs again. And then the light went out.

Names are important, but so is a sense of perspective, and I'd hate to
lose mine. So I'll let it rest with a few stories, all true, about the
importance of names. Perhaps you'll find them helpful counterpoints when
you're discussing FIND-NAME and someone who has only superficially read
the proposal suggests LOOKUP-THAT-DICTIONARY or HUNT-THRU-WORDLISTS as
alternatives.

The new UKIP party leader is one Dick Braine. OK, his politics are
atrocious, but even he as a registered right-wing fruit loop has
recognized that he can't even get the point of defending his beliefs
because of the problems (mainly hysterical laughter) that his name
provokes. He's considering changing his name.

It also reminds me of the 1981 Crosby by-election. It featured one Dick
Small (no giggling in the back of the class please) who, even though he
appeared on the ballot paper as Richard, did very badly indeed.

That election also had the boringly named John Desmond Lewis, who took
the opposite approach. He changed his name to Tarquin
Fin-tim-lin-bin-whin-bim-lim-bus-stop-F'tang-F'tang-Olé-Biscuitbarrel
representing the Looney Party. The name made it pretty obvious that he
wasn't very serious, and he unsurprisingly gained only 0.36% of the votes.


--
Alex

[Krishna Myneni]

On Mon, 19 Aug 2019 20:15:13 +0100, Alex McDonald wrote:

> On 19-Aug-19 17:49, Anton Ertl wrote:
>
>
>> It may happen that the name misleads the reader, but I think that this
>> effect is most pronounced on superficial reading, and vanishes for
>> people who explore a proposal in depth.
>

This discussion reminded of the title of a book by John Bell, "Speakable
and Unspeakable in Quantum Mechanics". Perhaps we should have Speakable
words and Unspeakable words in Forth. Though, I will say despite Anton's
annoyment, the NAME>x words would have been more accurately named,
NAMED>X , to indicate named words vs. unnamed words. Maybe there's even a
third category of UNMENTIONABLE words. And, of course, to accomodate
dxforth, we should also have UNFORGIVABLE words.

> Names are important, but so is a sense of perspective, and I'd hate to

> lose mine. ...

I don't subscribe to the notion that dubious past decisions should never
be revisited, even for word names, though there shouldn't be a rush to
propose changes to the standard. A few years of practical use will point
us in the right direction.

In the meantime,

[DEFINED] NAME>STRING [IF]
: NAMED>NAME-STRING NAME>STRING ;
[THEN]

etc.

KM

[Alex McDonald]

On 19-Aug-19 16:55, Anton Ertl wrote:
> Alex McDonald <al...@rivadpm.com> writes:
>> On 18-Aug-19 16:48, Anton Ertl wrote:
>>> Alex McDonald <al...@rivadpm.com> writes:
>>>> Anton mentions "almost" being forced to return EXECUTE or COMPILE, but
>>>> that leads to a smart COMPILE, to cope with the likes of S" which does
>>>> not have standard compilation semantics.
>>>
>>> It does not (and perverting COMPILE, in that way would be wrong).
>>> Here you can see how it can work with just EXECUTE and COMPILE,:
>>>
>>> \ let's redefine S" with named components (they are unnamed in
>>> \ Gforth, but the code is otherwise the same)
>>> : s"-int '"' parse save-mem ;
>>> : s"-comp '"' parse postpone sliteral ;
>>> ' s"-int ' s"-comp interpret/compile: s"
>>>
>>> \ now show the xts produced by NAME>INTERPRET and NAME>COMPILE for S"
>>> (') s" name>interpret ... drop \ prints "<1> `s"-int"
>>> (') s" name>compile ... 2drop \ prints "<2> `s"-comp `execute"
>>>
>>> As you can see, no need to pervert COMPILE, to deal with S".
>>>
>>> - anton
>>>
>>
>>
>> But that's not how the standard text interpreter works, because it
>> doesn't use FIND-NAME or NAME>xxx words.
>
> I assume you mean the classic user-defined text interpreter.

Yes.

>
>> To support NDCS we have
>>
>> 1. FIND returns an XT based on STATE.
>
> That's what Forth-94 suggests, what cmForth does, and what Gforth
> does.
>
>> 2. Compromised COMPILE,
>
> That's non-standard, or, as you write, compromised.
>
>> 3. IMMEDIATE STATE-smart words
>
> The Forth-94 committee probably intended that S" could be implemented
> in that way, but they guaranteed too much to allow that. The
> Forth200x committee occasionally discussed fixing that, but obviously
> none of us considered it important enough to write a proposal for that
> fix.
>
>> All these have been tried. All these have significant issues,
>
> What are the "significant issues" of variant #1?

It appears to have led the ANS committee to allow the circumstances
where some words have compilation semantics but are undefined for
interpretation. To the significant annoyance of some who find the lack
of consistency demands remedial disambiguificatory action; and we end up
with not only #1 but also #3 (IMMEDIATE STATE-smartness) giving us
indigestion.

>
>> and
>> there's not yet consensus on a "#4 Fix the problem with...".
>
> I am not even aware that #4 exists, apart from not supporting the

My point exactly.

> FIND-based user-defined text interpreter (which is not guaranteed in
> Forth-94 nor Forth-2012). But if we want to support it, the options

Is support of a classic text interpreter needed, or is it a nice-to-have
that we don't need?

Perhaps FIND needs replaced with FIND-NAME, and then NAME>xxx can
provide not only the correct COMPILE, or EXECUTE action but also the
correct XT.

--
Alex

[Anton Ertl]

Alex McDonald <al...@rivadpm.com> writes:
>On 19-Aug-19 16:55, Anton Ertl wrote:
>> Alex McDonald <al...@rivadpm.com> writes:
>>> To support NDCS we have
>>>
>>> 1. FIND returns an XT based on STATE.
>>
>> That's what Forth-94 suggests, what cmForth does, and what Gforth
>> does.
>>
>>> 2. Compromised COMPILE,
>>
>> That's non-standard, or, as you write, compromised.
>>
>>> 3. IMMEDIATE STATE-smart words
>>
>> The Forth-94 committee probably intended that S" could be implemented
>> in that way, but they guaranteed too much to allow that. The
>> Forth200x committee occasionally discussed fixing that, but obviously
>> none of us considered it important enough to write a proposal for that
>> fix.
>>
>>> All these have been tried. All these have significant issues,
>>
>> What are the "significant issues" of variant #1?
>
>It appears to have led the ANS committee to allow the circumstances
>where some words have compilation semantics but are undefined for
>interpretation.

That does not follow from #1, on the contrary: ANS Forth defines a
number of words with undefined interpretation semantics, and for these
words the desire for a state-independent single-xt FIND can be
satisfied. E.g., look at the current Gforth development version:

: cif c" if" ;
: ]find[ ] find postpone [ ;

cif find . ... drop \ prints "1 <1> `IF"
cif ]find[ . ... drop \ prints "1 <1> `IF"

As you can see, FIND returns the same values in either state in this
case.

The need for #1 comes from S", which has defined interpretation
semantics.

> To the significant annoyance of some who find the lack
>of consistency demands remedial disambiguificatory action;

That sentence is hard to parse, but anyway, there are many things for
which there is somebody who is significantly annoyed. That may be an
issue, but is not a "significant issue". For the latter I would like
to see an example of standard code that does not work as required by
the standard on a system than implements #1; I have provided such code
for #2 and #3.

>and we end up
>with not only #1 but also #3 (IMMEDIATE STATE-smartness) giving us
>indigestion.

You lost me here. If I have #1, I don't need #3.

>> FIND-based user-defined text interpreter (which is not guaranteed in
>> Forth-94 nor Forth-2012). But if we want to support it, the options
>
>Is support of a classic text interpreter needed, or is it a nice-to-have
>that we don't need?

I don't see any such requirement in Forth-94 or Forth-2012, although
it was probably intended. FIND is not specified in enough detail for
that. The proposal
<http://forth-standard.org/standard/core/FIND#reply-165> is intended
to fix that.

>Perhaps FIND needs replaced with FIND-NAME, and then NAME>xxx can
>provide not only the correct COMPILE, or EXECUTE action but also the
>correct XT.

Sure. FIND is obsolete. Still, those of us who want to support
legacy code containing FIND need to think about these issues.

[Anton Ertl]

The most recent (and therefore authoritative) version of the proposal
is <http://forth-standard.org/standard/core/FIND#reply-174>. You may
also look at the comments before that version.

[Alex McDonald]

Good on gforth; but a compliant system is not required to.

>
> The need for #1 comes from S", which has defined interpretation
> semantics.
>
>> To the significant annoyance of some who find the lack of
>> consistency demands remedial disambiguificatory action;
>
> That sentence is hard to parse, but anyway, there are many things
> for

Apologies, it was an uglification of the ugly word "disambiguifier";
that is : IF POSTPONE IF ; IMMEDIATE

> which there is somebody who is significantly annoyed. That may be
> an issue, but is not a "significant issue". For the latter I would
> like to see an example of standard code that does not work as
> required by the standard on a system than implements #1; I have
> provided such code for #2 and #3.
>
>> and we end up with not only #1 but also #3 (IMMEDIATE
>> STATE-smartness) giving us indigestion.
>
> You lost me here. If I have #1, I don't need #3.

: IF POSTPONE IF ; IMMEDIATE ( #1 )

I believe #1 is the incantation that gives us a guaranteed XT (FIND
doesn't have to find IF when in interpretation state).

I see that you noted in
http://forth-standard.org/standard/core/FIND#reply-165

| Note that this does not allow STATE-smart implementations of words
| without interpretation semantics (e.g., IF), but then, that's already
| forbidden by POSTPONE and [COMPILE].

: IF STATE @ IF POSTPONE IF ELSE ABORT" IF HAS NO INTERPRETATION
SEMANTICS" THEN ; IMMEDIATE ( #3 )

But that hasn't stopped some providing #3; they don't trust users to be
smart enough, and then fall into a STATE trap of their own making.

>
>>> FIND-based user-defined text interpreter (which is not guaranteed
>>> in Forth-94 nor Forth-2012). But if we want to support it, the
>>> options
>>
>> Is support of a classic text interpreter needed, or is it a
>> nice-to-have that we don't need?
>
> I don't see any such requirement in Forth-94 or Forth-2012, although
> it was probably intended. FIND is not specified in enough detail
> for that. The proposal
> <http://forth-standard.org/standard/core/FIND#reply-165> is intended
> to fix that.
>
>> Perhaps FIND needs replaced with FIND-NAME, and then NAME>xxx can
>> provide not only the correct COMPILE, or EXECUTE action but also
>> the correct XT.
>
> Sure. FIND is obsolete. Still, those of us who want to support
> legacy code containing FIND need to think about these issues.
>

FIND-NAME appears to have been on the books for some time. Is there any
discussion planned at the next standards meeting?


--
Alex

[Krishna Myneni]

On Tue, 20 Aug 2019 14:56:06 +0000, Anton Ertl wrote:

> Alex McDonald <al...@rivadpm.com> writes:
>>On 18-Aug-19 16:34, Anton Ertl wrote:
>>> Or you can just implement FIND-NAME-IN and FIND-NAME.
>>
>>There's a proposal under
>>http://forth-standard.org/standard/core/FIND#contribution-58. Is that
>>the authoritative RfD?
>
> The most recent (and therefore authoritative) version of the proposal is
> <http://forth-standard.org/standard/core/FIND#reply-174>. You may also
> look at the comments before that version.
>
> - anton

This is helpful. I was looking in the current Forth-2012 document for the
specification of FIND-NAME and it wasn't there.

KM

[Ruvim]

I agree, the names and naming conventions are very important.


Without holding a common naming convention we have such naming conflicts
as the following examples:

BUFFER vs BUFFER:
BUFFER: vs VALUE
FIELD: vs +FIELD
CHAR and CHARS vs CELL and CELLS
PARSE-NAME vs NAME>STRING [1]


Wrt the colon character — it seems a common pattern was that a
construction that starts with a name that contains colon (in the head or
tail) ends with a name that contains semicolon. But some new names was
appended without this pattern in the mind.

Also, the new construction "[: ... ;]" follows this pattern.
But "{: ... :}" — does not follow. Is it any reason for that?



In Recognizer RFD v4 it is suggested to add RECTYPE-NULL (that is not a
NULL), REC suffix (that is not a Record ), and 'RECTYPE:' that does not
ends with a name that contains semicolon.

Also, "*rec* type" means "*data* type", and these data types are
actually independent from the recognizers. So, why is it called 'rec'?




[1] See also some discussion at
https://forth-standard.org/standard/core/PARSE-NAME#contribution-92
https://forth-standard.org/standard/core/BUFFERColon#contribution-69


--
Ruvim

[A. K.]

You must have a very boring summertime. ;-)

[Ruvim]

On 2019-08-19 18:55, Anton Ertl wrote:
> Alex McDonald <al...@rivadpm.com> writes:

[...]

>> there's not yet consensus on a "#4 Fix the problem with...".
>
> I am not even aware that #4 exists, apart from not supporting the
> FIND-based user-defined text interpreter (which is not guaranteed in
> Forth-94 nor Forth-2012).

Why is not the FIND-based user-defined text interpreter guaranteed in
Forth-94?

As I can see, such text interpreter can work, but not all words
(lexemes) that are handled by a Forth system are guaranteed to be
handled by this text interpreter.


--
Ruvim

[dxforth]

On Monday, 26 August 2019 23:09:56 UTC+10, A. K. wrote:
> Am Montag, 26. August 2019 14:48:16 UTC+2 schrieb Ruvim:

> ...

> You must have a very boring summertime. ;-)

There's no accounting for taste :) Were it summer where I am I'd
be working with these. Seven years on it's grown faster from seed
than forth.

http://tinypic.com/r/20zelbm/9

[hughag...@gmail.com]

There is no "why" in regard to the ANS-Forth design.
Elizabeth Rather wasn't doing any thinking during the design.
She was focused on marketing:

On Tuesday, June 4, 2019 at 12:25:28 AM UTC-7, Elizabeth D. Rather wrote:
> On 6/3/19 8:43 PM, Manuel Rodriguez wrote:
> > The reason why mainstream languages like C++ and Python has become
> > successful is their large amount of library functions. What the users
> > are doing isn't to program code in C++, but they are using existing C++
> > libraries which were created by other.
>
> It is so like techies to assume there is a technical reason for the
> success or failure of something like a programming language. In fact,
> it's political/cultural. C was a product of Bell Labs, of awesome
> reputation in universities and other companies, and it was widely
> adopted -- not because it had libraries, but because "everyone" said it
> was The Thing. University Computer Science grad students and others
> developed and published libraries because it brought them professional
> recognition. At the same time, professional Forth programmers were just
> going around making things work without much recognition except for the
> hackers to made a splash in Byte Magazine.
>
> At the time, FORTH, Inc. was giving Forth systems to Universities, too,
> but since they hadn't been blessed by Bell Labs they were considered
> unprofessional.

So, one explanation for why FIND was broken in ANS-Forth
is that Elizabeth Rather is a blithering idiot.
She is not considering the fact that Forth Inc. Forth systems are
considered unprofessional because they are unprofessional (aka: "crap").

Another explanation for why FIND was broken in ANS-Forth
is that Elizabeth Rather wanted to prevent Forthers from writing
cross-compilers in Forth. The lack of a vectored LITERAL means
that using the built-in outer-interpreter won't work very well
because literal numbers in colon words won't be supported.
Writing a custom outer-interpreter won't work either, because
FIND is broken (the disambiguifiers fix FIND though).

Which explanation explains Elizabeth Rather breaking FIND like this?
These two proverbs are helpful in resolving that question:
----------------------------------------------------------
"Never attribute to malice that which can be explained by stupidity."
Hanlon's Razor

"Stupidity maintained long enough is a form of malice."
Richard Bos's corollary to Hanlon's Razor.
----------------------------------------------------------

[Ruvim]

On 2019-08-26 19:02, Ruvim wrote:
> On 2019-08-19 18:55, Anton Ertl wrote:
>> Alex McDonald <al...@rivadpm.com> writes:
> [...]
>>> there's not yet consensus on a "#4 Fix the problem with...".
>>
>> I am not even aware that #4 exists, apart from not supporting the
>> FIND-based user-defined text interpreter (which is not guaranteed in
>> Forth-94 nor Forth-2012).
>
> Why is not the FIND-based user-defined text interpreter guaranteed in
> Forth-94?

I meant, how this statement can be inferred from the Standard?

Do we have an example of a Forth-94 standard code that cannot be handled
by this text interpreter in some standard Forth system?

What conditions should be met for that?

> As I can see, such text interpreter can work, but not all words
> (lexemes) that are handled by a Forth system are guaranteed to be
> handled by this text interpreter.

I suppose that the standard words with undefined interpretation
semantics may be unfindable by FIND in a standard Forth system. It is a
consequence of an ambiguous condition on "attempting to obtain the
execution token [...] of a definition with undefined interpretation
semantics" from 4.1.2 Ambiguous conditions.

I also suppose that the same is true (must be true) for the standard
words with undefined execution semantics.

But, in the both cases, I don't sure that anybody else supports this view.


--
Ruvim

[Anton Ertl]

Ruvim <ruvim...@gmail.com> writes:
>On 2019-08-26 19:02, Ruvim wrote:
>> On 2019-08-19 18:55, Anton Ertl wrote:
>>> Alex McDonald <al...@rivadpm.com> writes:
>> [...]
>>>> there's not yet consensus on a "#4 Fix the problem with...".
>>>
>>> I am not even aware that #4 exists, apart from not supporting the
>>> FIND-based user-defined text interpreter (which is not guaranteed in
>>> Forth-94 nor Forth-2012).
>>
>> Why is not the FIND-based user-defined text interpreter guaranteed in
>> Forth-94?
>
>I meant, how this statement can be inferred from the Standard?

Take a look at
<http://forth-standard.org/standard/core/FIND#reply-165>. This
proposal is intended to fix this shortcoming. Compare it to the
current text of the specification of FIND, and you will see where the
current specification is not tight enough for the purpose of a text
interpreter.

>Do we have an example of a Forth-94 standard code that cannot be handled
>by this text interpreter in some standard Forth system?

Surprisingly, there is

: foo s" foo" ;
foo type

will not be handled correctly by Peter Faelth's 32-bit system
according to a posting a few weeks ago: On that system FIND produces
an xt for the interpretation semantics under all circumstances, but
the code above would require the text interpreter to produce an xt for
the compilation semantics (and yes, that system has different xts for
them).

Note that, even if all systems had a FIND that works for the classical
user-defined text interpreter, that would not mean that the standard
specification of FIND is tight enough. I would merely mean that a
tighter variant is common practice (and apart from that one system,
AFAIK it is).

>> As I can see, such text interpreter can work, but not all words
>> (lexemes) that are handled by a Forth system are guaranteed to be
>> handled by this text interpreter.

A text interpreter that does not work for all words counts as
non-working in my book.

>I suppose that the standard words with undefined interpretation
>semantics may be unfindable by FIND in a standard Forth system. It is a
>consequence of an ambiguous condition on "attempting to obtain the
>execution token [...] of a definition with undefined interpretation
>semantics" from 4.1.2 Ambiguous conditions.

Yes, you got one.

>I also suppose that the same is true (must be true) for the standard
>words with undefined execution semantics.

With your interpretation of xt, yes.