,---------------.
| Contributions |
`---------------´


,------------------------------------------
| 2019-09-18 12:32:53  UlrichHoffmann  wrote:
| proposal - VOCABULARY
| see: https://forth-standard.org/proposals/vocabulary#contribution-117
`------------------------------------------
# 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)



,---------.
| Replies |
`---------´


,------------------------------------------
| 2019-09-14 13:24:51  ruv  replies:
| comment - Ambiguous conditions
| see: https://forth-standard.org/standard/core/IMMEDIATE#reply-333
`------------------------------------------
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](https://forth-standard.org/standard/search#subsection.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.



,------------------------------------------
| 2019-09-16 01:34:00  ruv  replies:
| proposal - find-name
| see: https://forth-standard.org/proposals/find-name#reply-334
`------------------------------------------
### `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](https://forth-standard.org/standard/core/POSTPONE#contribution-98)). 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.