proposal - Revise Rationale of Buffer:

requestClarification - The case of undefined interpretation semantics

1. cmForth is virtually extinct, and not Standard in many other ways. Perhaps we should stop trying to accommodate it. It seems that with all current Forths, FIND will return an xt in interpretation mode whether the definition has interpretation semantics are not.

2. So remove the option that FIND may return caddr 0 in interpretation mode for words with no interpretation semantics. If the word is in the search order, FIND will return an xt regardless of STATE. The implementation of [DEFINED] using FIND always works as intended.

   The xt returned is always the execution token except:

   1. If the system provides words with dual semantics that may be ticked or POSTPONEd, the xt found while interpreting represents the interpretation semantics and that found while compiling represents the compiling semantics.

3. If the system can mark words as compile-only, a system-defined xt may be returned for such words while interpreting.

cmForth's trick was to have a special COMPILER vocabulary where all definitions were immediate and found only at compile time. That's very useful for simple cross-compiling; it ensures that no compiler words are accidentally compiled in the target. But that's a wnole other topic.

requestClarification - How can the zero result be used in a Standard program?

My point is that this would only be useful in a system that has some way to explicitly mark definitions as having no interpretation semantics.

requestClarification - The case of undefined interpretation semantics

To avoid the flaw connected with FIND, the specification of [DEFINED] should not mention FIND at all. In such case we will have two (or maybe three) variants: the basic one, the updating by Search-Order word set, and the possible updating by Recognizer word set.

I would also suggest to define and use lexeme term (in 2.1) to have an easier specification text.

The following definitions are a subject for discussion.

Basic variant

Parse a space-delimited lexeme. Return a true flag if the dictionary contains a definition name matching the lexeme; otherwise return a false flag.

Search-Order word set variant

Parse a space-delimited lexeme. Return a true flag if some word list from the search order contains a name matching the lexeme; otherwise return a false flag.

Recognizer word set variant

Parse a space-delimited lexeme. Return a true flag if the lexeme can be recognized by the system's recognizer sequence; otherwise return a false flag.

requestClarification - The case of undefined interpretation semantics

Surely with recognizers youu would check by searching for the name of appropriate the recognizer word?

comment - What is a standard program

"Standard Program" is defined in Section 5.2.1. There have been no problems with it not being in the definition of terms since 1994, so I doubt that including it will help much.

requestClarification - The case of undefined interpretation semantics

IIRC Mark Humphries' system does not find compile-only words when looking for interpreted words, but I don't know if it was published, and reconciling this system with NAME>COMPILE may be a challenge (NAME>INTERPRET should be ok thanks to the possible 0 result).

With the current recognizer proposal, if I want to check whether something is recognized, I do

s" $-5" forth-recognizer recognize

so I don't think that we should let [DEFINED] check recognized things outside the search order.

Given that, using the phrase "Parse /name/ delimited by space" is still appropriate.

As for having special versions in core and in the search-order wordset, this would spread from FIND to [DEFINED] [UNDEFINED] and FIND-NAME. I think the better approach is to define what "search order" means if there is no search-order wordset.

requestClarification - How can the zero result be used in a Standard program?

The standard defines words with undefined interpretation semantics, and some systems implement this in some way; that's the reason for allowing NAME>INTERPRET to return 0. If you know your system never returns 0 from NAME>INTERPRET, you do not need to write the program in that way, but for portable programs, you have to take this possibility into account.

comment - What is a standard program

I see now, thanks for the reference. I expected to find it it in (2.1) though.

It should be noted that (5.2.1) defines Standard Program in large — as end user application. But we used this term just for the fragments of code. More correct use in such case should look like "can this code fragment be a part of a standard program?". It seems too verbose. Perhaps standard code term could be more appropriate.

requestClarification - The case of undefined interpretation semantics

Don't you think that FIND should be declared as obsolescent sooner or later? I believe it should. At least due to its counted string argument — in favor of a word that takes (c-addr u) pair. From the perspective of FIND obsolescence it is better not to spread anything from it.

I agree that it is better to define what "search order" means in the specific cases.

Also, it is good to define non-parsing factor. For example: AVAILABLE ( c-addr u -- flag )

Regarding the recognizers.

I meant recognizable? example — it is a general method that should be able to also answer whether some word is defined (available) or not.

One use case for [DEFINED] looks like the following:

[defined] foo [if]
\ use foo
[else]
\ workaround
[then]

With recognizers the following situations can take place.

1. foo is not available via the search order, but it is available via a recognizer (for example, it is a word from SO library). The workaround actually should not be used.

2. foo is available via the search order, but the search order (the system's list of word lists) is not used due to the current recognizer sequence. Using foo will produce an error.

Therefore I doubt that only the search order should be checked. Actually, recognizers is a part of the search order in general sense.

requestClarification - The case of undefined interpretation semantics

There is no need for special AVAILABLE word (as non-parsing factor) if it is limited to the search order, since FIND-NAME (c-addr u -- nt|0 ) is enough.

proposal - Revise Rationale of Buffer:

Here's a possible text for the revised Rationale:

As a programmer, if your usage complies with the restrictions of BUFFER: (in particular, no adjacent initialized data that you want to treat as contiguous with the BUFFER: data), use BUFFER: instead of CREATE ALLOT, for image size reduction on some systems.

As a system implementor, you can put the BUFFER: data in uninitialized memory.