proposal - Call for Vote - Ambiguous condition in 16.3.3

Stephen Pelc

Call for Vote

Remove the ambiguous condition in 16.3.3

An ambiguous condition exists if a program changes the compilation word list during the compilation of a definition or before modification of the behavior of the most recently compiled definition with ;CODE, DOES>, or IMMEDIATE.

The ambiguous condition permits systems to use the <b>CURRENT wordlist to find the most recent name. Given the variety and complexity of recent wordlist structures, this apparent simplicity is rarely found compared to just updating a pointer for each name.

proposal - Interpretation semantic for locals are undefined

Stephen Pelc, 2 Sept 2020

See https://forth-standard.org/proposals/wording-declare-undefined-interpretation-semantics-for-locals#contribution-133

RUV states that interpretation semantics for locals are undefined.

This is true for (LOCAL) so we should add:

local Interpretation:

Interpretation semantics for this word are undefined.

LOCALS| refers to (LOCAL) so (LOCAL) covers the case.

For {: we need to add:

name Interpretation

The interpretation semantics of name are undefined

then remove the ambiguous condition in name Execution.

proposal - XML Forth Standard - migration from LaTeX to DocBook

How do you like the XML definition for words?

I like the tags used, very fitting for the task. What I am wondering about: If something new comes up, like the "TO name semantics" in Forth-2012, how easy is it to add that?

What I don't like are general problems of XML: extreme verbosity, and the need to escape > and < (probably also &); this is especially noticable in the testing section of the example. But you are the editor, so it's your decision, and if the next editor wants something better, the XML format allows automatic conversion to the next format (but it should also happen if the reverse direction is also possible, i.e., no information is lost).

Would your system/documentation also output this XML definitions for its own words?

Probably possible, but for now I don't see a benefit.

Any other related feedback?

How does this format cope with showing changes?

proposal - Remove the “rules of FIND”

SEARCH-WORDLIST is specified as "Find ... in the word list identified by wid". So "find" in 16.2 may be better defined as:

find: To search the search order or a wordlist for a definition name matching a given string.

or

find: To search (without qualification) the search order or (when a wordlist is mentioned) the wordlist for a definition name matching a given string.

proposal - Traverse-wordlist does not find unnamed/unfinished definitions

Author:

M. Anton Ertl

Change Log:

Initial version

Problem:

Does TRAVERSE-WORDLIST find unfinished or nameless definitions?

Solution:

It does not.

Proposal:

Change

Execute xt once for every word in the wordlist wid,

into

Execute xt once for every named word that can be found in the word list wid,

Insert, before "TRAVERSE-WORDLIST may visit ..."

A word that used to be findable in the wordlist but no longer is (because another word with the same name has been defined in the wordlist) may or may not be returned by TRAVERSE-WORDLIST.

Discussion

This is a wording change. The insterted sentence allows shadowed entries to be visited and reflects the sentence "Whether duplicated nodes are visited or not by TRAVERSE-WORDLIST is undefined." in the original proposal.

proposal - Remove the “rules of FIND”

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 or a specified wordlist for a definition name matching a given string.

Cross-reference 2.1 find and 16.2 find.

proposal - Call for Vote - Ambiguous condition in 16.3.3

Stephen Pelc

Call for Vote

Remove the ambiguous condition in 16.3.3

An ambiguous condition exists if a program changes the compilation word list during the compilation of a definition or before modification of the behavior of the most recently compiled definition with ;CODE, DOES>, or IMMEDIATE.

The ambiguous condition permits systems to use the <b>CURRENT wordlist to find the most recent name. Given the variety and complexity of recent wordlist structures, this apparent simplicity is rarely found compared to just updating a pointer for each name.

proposal - Traverse-wordlist does not find unnamed/unfinished definitions

What is a rationale to allow TRAVERSE-WORDLIST to miss nt for a shadowed word?

In any case, a Forth system cannot reuse the same nt for the different definition (i.e., that has the different behavior), since this nt (literally) could be already compiled by a program.

Also, for better reflection, TRAVERSE-WORDLIST should return nt for every word that was placed into a word list (and that wasn't excluded as the result of a word created by MARKER).

IIRC, years ago a kind of recognizer was suggested by Michael Gassanenko to access the shadowed words.

proposal - Traverse-wordlist does not find unnamed/unfinished definitions

The idea was that some system might have a hash table that contains each name only once (i.e., the latest definition). Of course, a system that implements MARKER or FORGET would not go there. There probably are no such systems, so if somebody proposes to eliminate this option, there may be little resistance, but I am reluctant to do this in this proposal, which is intended to just be a wording change.

proposal - Call for Vote - Ambiguous condition in 16.3.3

A Forth system may use the different memory sections for the different word lists (for example, it may use the different section for the system's and for user-defined word lists). This approach is used in SP-Forth. Changing the compilation word list causes changing the current section. So changing the compilation word list during compilation will produce incorrect code.

If we remove the mentioned ambiguous condition, we destandardize such Forth systems and prohibit such approach in implementations.

Also, by this changing, we, without any profit, destandardize and prohibit the approach when nt is actually created by semicolon ; (I uses this approach).

Concerning using CURRENT to find the most recent name — this approach is used in my system.

It seems for me that complexity of wordlist structures is an argument that it can have one more cell to keep the reference to its most recent nt.

proposal - Nestable Recognizer Sequences

Some remarks:

• Is it a good idea to have defining words such as rec-sequence and id-creating words such as wordlst both in the standard? Seems to be inconsistent to me.

• Isn't the Forth way to chain execution tokens to put them in colon definitions? Why do we need req-sequence?

proposal - Remove the “rules of FIND”

Replace the text in [DEFINED]

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 or a specified wordlist for a definition name matching a given string.

Cross-reference 2.1 find and 16.2 find.

requestClarification - Why RECURSE is needed?

This his been discussed by the TC and we deem the replies above by Anton Ertl and Peter Knaggs to clarify the question.

As to smudging: this is not used in the standard any more.

referenceImplementation - sample implementation that can also be interpreted

The TC agrees that ruv's response is correct.

requestClarification - Word set of S>D word

The Technical committee has considered your submission.

The number conversion words <# # #S #> and friends require double numbers.

In order to use these words to display both single and double numbers S>D is required. Therefore we leave S>D in the CORE word set.