FIND-NAME tests cases use missing words

[SirWumpus]

Forth 200x draft 19-1 section F. Test Suite page 318.

• There are several words referenced with no definition bla" ble" bli". Am I missing something?
• Also the tests assume FIND-NAME-IN is implemented even though it assumes Search-Order word set support. These should be separate from FIND-NAME IMO.
• Some tests use Locals word set, again an optional word set.

[ruv]

There are several words referenced with no definition bla" ble" bli". Am I missing something?

They are not words, they are parsed text.

\ The phrase
T{ S\" s\"" FIND-NAME NAME>INTERPRET EXECUTE bla" S" bla" COMPARE -> 0 }T
\ is equivalent to:
T{ ' s" EXECUTE bla" S" bla" COMPARE -> 0 }T
\ That is equivalent to:
T{ s" bla" S" bla" COMPARE -> 0 }T
\ Note that `s"` is lowercase. It should be uppercase to be compliant with standard systems that do not support lower case.

The following test case is similar:

T{ : fnt9 [ S\" s\"" FIND-NAME NAME>COMPILE EXECUTE ble" ] ; -> }T
T{ fnt9 S" ble" COMPARE -> 0 }T

I think, this test case is inconsistent. Note that the xt returned by name>compile is executed in interpretation state. In the same time, Forth-2019 A.15.6.2.1909.10 says:

In a traditional xt+immediate-flag system, the x xt returned by NAME>COMPILE is typically xt1 xt2,
where xt1 is the xt of the word under consideration, and xt2 is the xt of EXECUTE (for immediate
words) or COMPILE, (for words with default compilation semantics).

It means that xt returned by name>compile shall be executed only in compilation state to perform the compilation semantics of an unordinary word (or, in the general case). And the word s" must not be an exception.

Otherwise, if we allow to perform this xt in interpretation state in general case, xt2 should not be the xt of execute for immediate words, but xt of execute-compiling.

[SirWumpus]

The following appears to be incomplete, leaving 2 values on the stack before ending the definition ;.

T{ : fnt9 [ S\" s\"" FIND-NAME NAME>COMPILE EXECUTE ble" ] ; -> }T

2LITERAL should be added and as mentioned above change to NAME>INTERPRET:

T{ : fnt9 [ S\" s\"" FIND-NAME NAME>INTERPRET EXECUTE ble" ] 2LITERAL ; -> }T

[SirWumpus]

: fnta FIND-NAME NAME>INTERPRET EXECUTE ; IMMEDIATE
T{ : fntb [ S\" s\"" ] fnta bli" 2LITERAL ; -> }T

For similar reasons stated above, shouldn't NAME>INTERPRET actually be NAME>COMPILE ?

[SirWumpus]

: fnta FIND-NAME NAME>INTERPRET EXECUTE ; IMMEDIATE
T{ : fntb [ S\" s\"" ] fnta bli" 2LITERAL ; -> }T

For similar reasons stated above, shouldn't NAME>INTERPRET actually be NAME>COMPILE ?

The above appears to have a 2LITERAL that causes a stack underflow; think the test should be:

T{ : fntb [ S\" s\"" ] fnta bli" ; -> }T

[SirWumpus]

Something that is not indicated for some tests is that some newlines are significant. In particular these two tests:

\ Note the newlines are significant.
T{ fnt-interpret-words fnt5 VALUE fntd fnt6 TO fntd fntd
-> fnt6 }T
T{ fnt-interpret-words S" yyy" : fnte S" yyy" ; fnte COMPARE
-> 0 }T

[ruv]

execute-compiling is not defined in the Forth 200x draft.

Yes. But I don't see, what follows from that.

The following appears to be incomplete, leaving 2 values on the stack before ending the definition ;.

T{ : fnt9 [ S\" s\"" FIND-NAME NAME>COMPILE EXECUTE ble" ] ; -> }T

If you define name>compile in post4 as:

: name>compile ( nt -- x xt )
  dup immediate? if ['] execute-compiling exit then  ['] compile,
;

then Post4 will pass this test. OTOH, I do not sure that name>compile should be implemented in this way. Because that solves only the problem of name>compile; the problem of name>interpret cannot be solved at all (see bellow). Therefore, it is better to change the specifications for both of them. As a result, these test cases will become formally incorrect and will be updated.

For similar reasons stated above, shouldn't NAME>INTERPRET actually be NAME>COMPILE ?

That testcase checks both find-name and name>interpret. If we use name>compile, we won't check name>interpret.

There is a problem with how name>interpret is specified in the standard, which leads to a problem with this testcase.

1. If the execution semantics of an immediate word depend on STATE, then the execution token of this word does not identify the interpretation semantics of this word.
2. In the same time, for an immediate word, name>interpret returns the execution token of the word, both by intention, and in actual implementations. And it conflicts with what is formally specified (i.e., that name>interpret returns xt that identifies the interpretation semantics of the word).
3. The testcase checks what is formally specified, but due to that conflict, the testcase cannot be passed in the general case.

The problem can be observed only for immediate words whose execution semantics depend on STATE. Your word S" is implemented in this way, so we can observer the problem.

There are several proposals that try to fix this problem in the standard, the process is in progress.