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


,------------------------------------------
| 2020-09-01 17:41:58  AntonErtl  wrote:
| proposal - Traverse-wordlist does not find unnamed/unfinished definitions
| see: https://forth-standard.org/proposals/traverse-wordlist-does-not-find-unnamed-unfinished-definitions#contribution-153
`------------------------------------------
## Author:

M. Anton Ertl

## Change Log:

Initial version

## Problem:

[Does TRAVERSE-WORDLIST find unfinished or nameless definitions](https://forth-standard.org/standard/tools/TRAVERSE-WORDLIST#contribution-118)?

## Solution:

It does not.


## Proposal:

Change

> Execute xt once for every word in the wordlist wid,

into

> Execute xt once for every named and findable word in the wordlist wid,


## Discussion

This is a wording change.  The use of "findable" is taken from it's use in the definition of ":" an DOES>.  Possible problem: A shadowed word is not findable with FIND, FIND-NAME-IN etc, but may be reached with TRAVERSE-WORDLIST.


,------------------------------------------
| 2020-09-01 21:16:26  GeraldWodni  wrote:
| proposal - XML Forth Standard - migration from LaTeX to DocBook
| see: https://forth-standard.org/proposals/xml-forth-standard-migration-from-latex-to-docbook#contribution-154
`------------------------------------------
## Author:
Peter Knaggs

## Problem & Solution:
The author, who is also the editor of the Forth Standard is considering migrating from LaTeX to XML.
The idea being that XML is easier to parse for machines while maintaining being editable by humans.
[Please read the proposed PDF](/files/proposals/xml.pdf).
More material including [DTD, TEX, HTML and the XML example below](/files/proposals/xml.zip).

## Tools:
> I have
> been thinking of using either XML Notepad or XXE (XMLmind XML Editor)
> as the editor environment and move the whole standard into DocBook.
> That way I get PDF, XHTML and EPUB with very little work.

## Feedback:
At this stage the author is asking for feedback:
- How do you like the XML definition for words?
- Would your system/documentation also output this XML definitions for its own words?
- Any other related feedback?

## Example Code:
```xml
<wordlist>
<worddef name="DOES&gt;" id="core:DOES" number="1250" wordlist="CORE" english="does">
	<description>
		<interpret>
			Interpretation semantics for this word are undefined.
		</interpret>

		<compile>
			<stack type="C">
				<pre>colon-sys_1</pre>
				<post>colon-sys_2</post>
			</stack>
			<para>
				Append the run-time semantics below to the current
				definition.
				Whether or not the current definition is rendered
				findable in the dictionary by the compilation of
				<word word="core:DOES" /> is implementation defined.
				Consume <param>colon-sys_1</param> and produce
				<param>colon-sys_2</param>. Append the initiation
				semantics given below to the current definition.
			</para>
		</compile>
		<runtime>
			<stack></stack>
			<stack type="R"><pre>next-sys_1</pre></stack>
			<para>
				Replace the execution semantics of the most recent
				definition, referred to as <param>name</param>, with
				the <param>name</param> execution semantics given
				below. Return control to the calling definition
				specified by <param>nest-sys_1</param>. An ambiguous
				condition exists if <param>name</param> was not
				defined with <word word="core:CREATE" /> or a
				user-defined word that calls <word word="core:CREATE"/>.
			</para>
		</runtime>
		<init>
			<stack>
				<pre>i*x</pre>
				<post>i*x a-addr</post>
			</stack>
			<stack type="R">
				<post>next-sys_1</post>
			</stack>
			<para>
				Save implementation-dependent information
				<param>nest-sys_2</param> about the calling definition.
				Place <param>name</param>'s data field address on the
				stack. The stack effects <param>i*x</param> represent
				arguments to <param>name</param>.
			</para>
		</init>
		<execute type="name">
			<stack>
				<pre>i*x</pre>
				<post>j*x</post>
			</stack>
			<para>
				Execute the portion of the definition that begins with
				the initiation semantics appended by the
				<word word="core:DOES" /> which modified
				<param>name</param>. The stack effects <param>i*x</param>
				and <param>j*x</param> represent arguments to and
				results from <param>name</param>, respectively.
			</para>
		</execute>
		<see>
			<wref word="core:CREATE" />
		</see>
	</description>
	<rationale>
		<para>
			Typical use:
			<c>: X ... DOES&gt; ... ;</c>
		</para><para>
			Following <word word="core:DOES" />, a Standard Program
			may not make any assumptions regarding the ability to find
			either the name of the definition containing the
			<word word="core:DOES"/> or any previous definition whose
			name may be concealed by it. <word word="core:DOES" />
			effectively ends one definition and begins another as far
			as local variables and control-flow structures are
			concerned.
			The compilation behavior makes it clear that the user is
			not entitled to place <word word="core:DOES"/> inside any
			control-flow structures.
		</para>
	</rationale>
	<testing>
		<test><pre>: DOES1 DOES&gt; @ 1 + ;</pre><post></post></test>
		<test><pre>: DOES2 DOES&gt; @ 2 + ;</pre><post></post></test>
		<test><pre>CREATE CR1</pre><post> </post></test>
		<test><pre>CR1  </pre><post>HERE</post></test>
		<test><pre>1 ,  </pre><post> </post></test>
		<test><pre>CR1 @</pre><post>1</post></test>
		<test><pre>DOES1</pre><post> </post></test>
		<test><pre>CR1  </pre><post>2</post></test>
		<test><pre>DOES2</pre><post> </post></test>
		<test><pre>CR1  </pre><post>3</post></test>

		<test><pre>: WEIRD: CREATE DOES&gt; 1 + DOES&gt; 2 + ;</pre><post></post></test>
		<test><pre>WEIRD: W1</pre><post></post></test>
		<test><pre>' W1 &gt;BODY</pre><post>HERE   </post></test>
		<test><pre>W1       </pre><post>HERE 1 +</post></test>
		<test><pre>W1       </pre><post>HERE 2 +</post></test>
	</testing>
</worddef>
</wordlist>

```


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


,------------------------------------------
| 2020-09-01 14:18:46  GeraldWodni  replies:
| proposal - Multi-Tasking Proposal
| see: https://forth-standard.org/proposals/multi-tasking-proposal#reply-451
`------------------------------------------
An implementation by Andrew Haley can be found here: https://sourceforge.net/projects/concurrentforth/


,------------------------------------------
| 2020-09-01 15:31:12  BerndPaysan  replies:
| proposal - Remove the “rules of FIND”
| see: https://forth-standard.org/proposals/remove-the-rules-of-find-#reply-452
`------------------------------------------
Replace the parenthesis text “(according to the rules in the system's FIND)” with “in the current search order”. Since we don't have a term “search order” in the definitions of terms, section 2, only in the search order word set, move that to the definition of terms, and change it:

*search order:*
A list of word lists specifying the order in which the dictionary will be searched.  If the search order wordset is not present, the search order consists of all the word lists that contain definitions.

to the definitions of terms.


,------------------------------------------
| 2020-09-01 16:17:01  GeraldWodni  replies:
| proposal - VOCABULARY
| see: https://forth-standard.org/proposals/vocabulary#reply-453
`------------------------------------------
# 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 ( -- )
         WORDLIST CREATE , 
       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)



,------------------------------------------
| 2020-09-01 17:43:40  AntonErtl  replies:
| comment - Unfindable definitions
| see: https://forth-standard.org/standard/tools/TRAVERSE-WORDLIST#reply-454
`------------------------------------------
Addressed in  [this proposal](https://forth-standard.org/proposals/traverse-wordlist-does-not-find-unnamed-unfinished-definitions).


,------------------------------------------
| 2020-09-01 19:34:59  BerndPaysan  replies:
| proposal - Remove the “rules of FIND”
| see: https://forth-standard.org/proposals/remove-the-rules-of-find-#reply-455
`------------------------------------------
Replace the text

> Return a true flag if *name* is the name of a word that can be found (according to the rules in the system's FIND); otherwise return a false flag.

with

> Try to find *name.*  Return a true flag if *name* can be found; otherwise return a false flag.

Add the following redefinition of the term “find” to 16.2:

> **find:**
> To search the search order for a definition name matching a given string.

Cross-reference 2.1 find and 16.2 find.