Digest #83 2019-09-19
version uh 2019-09-18
Add the following section to the Forth-200x standard in the optional Search-Order word set to the Search-Order extension word list.
( "<spaces>name" -- )
Skip leading space delimiters. Parse name delimited by a space. Create a definition for name with the execution semantics defined below. Create a new empty word list wid and associate it with name.
name is referred to as a "vocabulary".
( -- )
Replace the first word list in the search order by the word list wid that is associated with the vocabulary. An ambiguous condition exists if there are no word lists in the search order.
See: 22.214.171.1240 WORDLIST 16.6.2.0715 ALSO 126.96.36.1998 PREVIOUS 188.8.131.525 GET-ORDER 184.108.40.2067 SET-ORDER
Rationale: VOCABULARY has been used in traditional Forth systems and it is available with consistent behaviour in many standard systems. So it seems worthwhile to standardize it (again, it has been standardized in Forth-83).
VOCABULARY Assembler ONLY FORTH ALSO Assembler DEFINITIONS ( set search order to ... FORTH Assembler Assembler )
: VOCABULARY ( -- ) CREATE WORDLIST , DOES> ( -- ) @ >R GET-ORDER SWAP DROP R> SWAP SET-ORDER ;
Add the following ambigous condition to 220.127.116.11:
- executing a vocabulary word when the search order is empty (18.104.22.16800)
The standard allows the implementations where
IMMEDIATE affects the last definition in the compilation word list. It is the only reason for the following ambiguous condition (from 16.3.3):
An ambiguous condition exists if a program changes the compilation word list [...] before modification of the behavior of the most recently compiled definition with [...]
Also the following ambiguous condition (also from 16.3.3) allows to place the current definition name into the compilation word list only on Semicolon:
An ambiguous condition exists if a program changes the compilation word list during the compilation of a definition
TRAVERSE-WORDLIST, a colon-definition name should be placed into the compilation word list only on Semicolon (and not before). Otherwise it would be strange that some name can be unfindable via
SEARCH-WORDLIST but available via
Therefore, I think it is an ambiguous condition in the example above.
NAME>INTERPRET for STATE-smart implementation of
NAME>INTERPRET ( nt -- xt )and
NAME>COMPILE ( nt -- xt1 xt2 )are fine with a STATE-smart implementation of
TO: xt and xt1 are the same, and represent the STATE-smart definition. xt2 is the xt of
EXECUTE. If the standard allowed a STATE-smart implementation of FILE
S", it would be the same.
The issue is that in this case
( xt1 'execute ) doesn't represent the compilation semantics of
TO. Usually, to perform the compilation semantics we need to just execute xt2 (regardless of the STATE, even in interpretation state). But in this case we need to also set compilation state before execution xt2. Therefore,
( xt1 'execute ) does not bring all required information to perform the compilation semantics. Therefore, it does not represent the compilation semantics. Actually, it represents the execution semantics of
A possible solution is to return
( xt1 'execute-compiling ) — they brings all required information to perform the compilation semantics of
EXECUTE-COMPILING in the comment for POSTPONE). But this solution cannot be used for
( xt ) doesn't represent the interpretation semantics of
TO, since it doesn't bring all required information, namely that we need to set interpretation state. But in this case we don't have a place to return special
NAME>INTERPRET is not fine with a STATE-smart implementation of "dual-semantics" words.