[117] 2019-09-18 12:32:53 UlrichHoffmann wrote:

proposal - VOCABULARY

Vocabulary proposal

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.

---

16.6.2.3000 VOCABULARY
( "<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".

name Execution:
( -- )
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: 16.6.1.2460 WORDLIST 16.6.2.0715 ALSO 16.6.2.2038 PREVIOUS 16.6.1.2195 GET-ORDER 16.6.1.2197 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).

Typical use:

VOCABULARY Assembler

ONLY FORTH ALSO Assembler DEFINITIONS ( set search order to  ... FORTH Assembler Assembler )

Reference Implementation:

: VOCABULARY ( -- )
     CREATE WORDLIST , 
   DOES> ( -- ) @ 
      >R GET-ORDER SWAP DROP 
      R> SWAP SET-ORDER ;

Other additions

Add the following ambigous condition to 16.4.1.2:

• executing a vocabulary word when the search order is empty (16.6.2.3000)

[r333] 2019-09-14 13:24:51 ruv replies:

comment - Ambiguous conditions

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 [...] IMMEDIATE

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

Actually, having 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 TRAVERSE-WORDLIST.

Therefore, I think it is an ambiguous condition in the example above.

[r334] 2019-09-16 01:34:00 ruv replies:

proposal - find-name

NAME>INTERPRET for STATE-smart implementation of TO

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

A possible solution is to return ( xt1 'execute-compiling ) — they brings all required information to perform the compilation semantics of TO (see EXECUTE-COMPILING in the comment for POSTPONE). But this solution cannot be used for NAME>INTERPRET.

Similarly, ( 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 'execute-interpreting.

So NAME>INTERPRET is not fine with a STATE-smart implementation of "dual-semantics" words.