proposal - Remove the “rules of FIND”

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 (may contain only one word list).

to the definitions of terms.

comment - Ambiguous condition could be removed

@ruv: Your implementation sketch is not complete enough to be sure what the plan is.

If your plan is to special-case some system-defined words (in particular, TO, IS, ACTION-OF) in POSTPONE and append their compilation semantics rather than STATE-smart semantics, yes, this can work. A system implementor can even do it by temporarily setting STATE at run-time around the execution of the STATE-smart semantics, because the implementation of these words are the job of the system implementor (i.e., even if the source code looks like the word is STATE-smart, it does not have to behave like a STATE-smart word, while a user-defined STATE-smart word actually has to behave as a STATE-smart word). You should then also special-case dual words in ' and ['].

Does this mean we can remove the ambiguous condition? That depends on whether we want system implementors who have implemented TO, IS and ACTION-OF as STATE-smart words without this special-casing to change their implementation. Looking at the behaviour of S" in SwiftForth (it behaves as a STATE-smart rather than dual word), I don't expect SwiftForth to change even if you remove the ambiguous condition; unless a customer complains, but they apparently have not about S".

@JennyBrien: You want to replace a restriction on POSTPONEing three words with a restriction on POSTPONEing all but a very few words. No thanks.

As for the useful purpose: If you write code generators with parameters, it's more convenient to call the code generator interpretively. Say, something like

: sort [ ' < ' swap ' @ ' ! gen-quicksort ] ;
: fsort [ ' f< ' fswap ' f@ ' f! gen-quicksort ] ;

In any case, existing standard code such as my garbage collector does this. You would have to give a good reason to destandardize this code.

, but it seems that you want to support STATE-smart implementations of TO etc. by

comment - Ambiguous condition could be removed

@JennyBrien: You want to replace a restriction on POSTPONEing three words with a restriction on POSTPONEing all but a very few words. No thanks.

As for the useful purpose: If you write code generators with parameters, it's more convenient to call the code generator interpretively. Say, something like

: sort [ ' < ' swap ' @ ' ! gen-quicksort ] ;
: fsort [ ' f< ' fswap ' f@ ' f! gen-quicksort ] ;

```

In any case, existing standard code such as my garbage collector does this. You would have to give a good reason to destandardize this code.

I understand now. It wasn't one of my brighter ideas. There's not a great deal of use for POSTPONE TO or POSTPONE S" , but I was trying to see if there were sensible restrictions that would make STATE-smart implementations of dual words unproblematic. I can see that if you do this sort of thing regularly, you would come to hate STATE-smartness with a passion.

proposal - Case sensitivity

Reference implementation

To support this feature, it is enough to just create the lower-case synonyms for the standard words.

Using full-fledged SYNONYM (that is going to be standardized), it can be done even as a standard code.

For simplicity, I would suggest to not require supporting [IF] [ELSE] [THEN] in lower case.

proposal - Case insensitivity

Testing

I think, it is better to use SEARCH-WORDLIST in Testing, — to get a careful failing of the test (if any) and avoid a "not-found" stop-error.

Effect on performance

Comparing to my proposal (that is to support lower case only) — this solution affects performance more significant.

By my test in SP-Forth, the lowercase synonyms of the standard words yields +23-24% in time of SEARCH-WORDLIST (for FORTH-WORDLIST wordlist), when insensitive search yields 51-71% in time.

Also, lowercase approach affects only FORTH-WORDLIST, when case-insensitive approach affects any wordlist. In some use-cases it can be critical (for example, when a wordlist is used for case-sensitive file names).

OTOH, synonyms approach perhaps require more space.

Optionality

What do you think to have a standard API to change this case-sensitivity?

I.e. if a standard Forth system supports case-insensitive search, it should also supports this API to turn off (or turn on) case-sensitivity?

Or, maybe, a separate word for case-sensitive search?

proposal - Case insensitivity

Clarification of "my proposal (that is to support lower case only)" — I meant, to support lower case only (and not mixed case) in addition to upper case of the standard words.

Regarding use of mixed case in my proposal. In practice, it is used for some several standard words only. If a user wants to use mixed case for some words, he have to just create the synonyms for these words in the wanted case.

proposal - Clarify FIND

6. POSTPONE and STATE-smartness

@Anton, in your comment you hadn't shown that "suggested implementation of POSTPONE does not work correctly" but vice versa: "this can work". I'm even going to provide a working Forth system for your test later.

So, the original specification for FIND and POSTPONE does not disallow the STATE-smart implementations for the words with unspecified execution semantics.

Hence, the updated specification should not disallow it too.

3. Performing the returned xt in the different STATE

I meant the following state from your proposal:

If the definition is for a word for which POSTPONE is ambiguous, it is ambiguous to perform the xt returned by FIND in a STATE different from the STATE during FIND.

It has the following issues:

a) The rule "POSTPONE is ambiguous" isn't enough robust (since this ambiguity can be eliminated), and it isn't enough at all (due to possible STATE-smart implementations of the words with undefined interpretation semantics).

b) The state "it is ambiguous to perform the xt returned by FIND in a STATE different from the STATE during FIND" means that the returned pair (xt 1), that can be produced in compilation state, does not represent the compilation semantics: since from this pair you don't know do you need to set compilation state or not before executing xt.

4. Possible implementation of some words (like TO) via Recognizer API

I should have mentioned the examples.

a) See dual-semantics-via-recognizer.example

b) See c.l.f. messages: news://qi9c8i$df1$1@gioia.aioe.org, news://qi9am4$703$1@gioia.aioe.org.

It seems that such implementation of TO is not disallowed by Forth-2012 standard, but will be disallowed by the proposed update specification for FIND.

requestClarification - description of "nt" in the standard

You want to move the first sentence of 15.3.1 into a new section "15.2.1 Definition of terms"?

I did not think about this, but it seems reasonable — yes, but Into the existing section "15.2. Additional terms and notation". See also "16.2" for comparison.

The nt does not identify the name, but the named word (or named definition, if you prefer)

Have a look at the following definition (from "16.2")

compilation word list: The word list into which new definition names are placed.

Thanks to SYNONYM, one definition can have several names. And TRAVERSE-WORDLIST will produce different nt for each name (even for the same definition) that was placed into the word list. Therefore it is better to say that nt identifies a definition name (as a word list entry).

There is an open question about uniqueness of nt when the name and behavior are the same. Technically, SYNONYM DUP DUP can associate the same nt for newname. This situation can be detected via TRAVERSE-WORDLIST therefore it should be specified. And the answer depend on the name token term definition.

May TRAVERSE-WORDLIST produce the same nt twice (for the same or different wid) or omit the nt for some name that was placed into a word list?

proposal - Case insensitivity

The wording of the proposal should leave a way out for case sensitive systems; they will not go away and likely comply with other parts of the standard to keep them in.

At the moment, we have programs with environmental dependency on case insensitivity. This will go away when case insensitivity in one way or the other is added.

After acceptance, a system that still is case sensitive shall have an environmental restriction on programs using all-uppercase standard words; it's not non-standard, it's just restricting programs.

comment - [ELSE] without preceding [IF]

Add to the Rationale:

An isolated [ELSE] ... [THEN] will skip the code up to the [THEN]. Wrapping this later into an [IF] ... [THEN] will break that, so don't do that.

comment - Ambiguous condition could be removed

We have discussed this at the standards meeting and have come to the conclusion that proper implementation of dual semantics words are not sufficiently common to change the ambiguous condition.

referenceImplementation - GNU C RESTRICT would make sense in the standard

This has been discussed at the standards meeting, we do not think that a proposal of this nature would achieve consensus. Common practice has not yet been established. This feeds into related topics such as dual semantic words, that are being discussed.

proposal - Remove the “rules of FIND”

Replace "(may contain only one word list)" with a new sentence: If the search order wordset is not present, the search consists of all the word lists that contain definitions.

This should also include systems like cmForth which don#t have the search order wordset, but search several word lists in some circumstances.

referenceImplementation - The reference implementation is incorrect

Almost. I would put the BEGIN in before the POSTPONE [.

: QUIT
   ( empty the return stack and set the input source to the user input device )
   BEGIN
     POSTPONE [
     REFILL
   WHILE
     ['] INTERPRET CATCH
     CASE
     0 OF STATE @ 0= IF ." OK" THEN CR ENDOF
     -1 OF ( Aborted ) ENDOF
     -2 OF ( display message from ABORT" ) ENDOF
     ( default ) DUP ." Exception # " .
     ENDCASE
   REPEAT BYE
;

referenceImplementation - The reference implementation is incorrect

Ok, looking at it once more: Only in the error exit POSTPONE [ is necessary. So:

: QUIT
   ( empty the return stack and set the input source to the user input device )
   POSTPONE [
   BEGIN
     REFILL
   WHILE
     ['] INTERPRET CATCH
     CASE
     0 OF STATE @ 0= IF ." OK" THEN CR ENDOF
     POSTPONE [
     -1 OF ( Aborted )  ENDOF
     -2 OF ( display message from ABORT" ) ENDOF
     ( default ) DUP ." Exception # " .
     ENDCASE
   REPEAT BYE
;

requestClarification - POSTPONE [IF]

I, (on behalf of the TC) suggest to remove the ambiguous condition, and change the rationale, to add information that defining some new [UNLESS] scanning words by just postponing [IF], [ELSE] or [THEN] is not enough. You also need to add the new word [UNLESS] to the scanner inside [IF], so that nesting works. That might be possible in high quality implementations, but it is outside the scope of this standard.

comment - Ambiguous condition in case of undefined execution semantics

We have reviewed this at the standards meeting. This is being folded into a proposal coming to you in the near future.

requestClarification - Getting the block contents

The committee considered this and decided to write a proposal along the lines of : add the comment "XXXX may call BLOCK or BUFFER and so may invalidate a currently used BUFFER", for "XXXX" = LOAD, THRU and LIST, to each of their respective definitions.

comment - Ambiguous conditions

Answer for the TC:

: creates a new definition. Therefore, in the example above, bar is the most recent definition, and should be affected by immediate. This is not ambiguous.