6.1.1360 EVALUATE CORE

Both John Hayes' core test program and the specification for SOURCE already have this test case:

: GS1 S" SOURCE" 2DUP EVALUATE
       >R SWAP >R = R> R> = ;
T{ GS1 -> \<TRUE\> \<TRUE\> }T

which does the same thing, albeit less efficiently.

However it is implemented, after finishing EVALUATE, SOURCE-ID has to produce the previous value. I think that follows from the definition of "input source specification" in 2.1, but it's not that explicit there.

SAVE-INPUT and RESTORE-INPUT only work within one input source (and probably not for the user input device), so saving and restoring SOURCE-ID is not necessary. You may save it and then check it on RESTORE-INPUT, but this does not guarantee that only correct uses of RESTORE-INPUT come through. Consider

s\" save-input s\" restore-input\" evaluate" evaluate

Consider two nested EVALUATEs, or a nesting EVALUATE-INCLUDED-EVALUATE.

To augment Stephens question: is the 2nd test supposed to work?

: warp-c
    cr ." Wrapper-name: " parse-name type
       ."   Forth-name: " parse-name type ;

\ this one works
cr ." TEST ONE"
s\" warp-c wone fone" evaluate

\ this one does not on all systems
cr ." TEST TWO"
s\" warp-c wone fone\nwarp-c wtwo ftwo\n" evaluate

3.4.1.1 says

The set of conditions, if any, under which a "space" delimiter matches control characters is implementation defined.

So the standard makes no guarantees to programs wrt space-delimited parsing, with one exception: 11.3.5 says:

When parsing from a text file using a space delimiter, control characters shall be treated the same as the space character.

But AFAICS in EVALUATE, a standard system may choose to treat only BL as delimiter in that case, or it can also treat other control characters (including newline characters) as space delimiters. I recommend the latter.

When parsing with delimiters other than space (and none of the newline characters), the newline characters must be treated like any other non-delimiter. And when parsing with a newline character as delimiter, that character has to be treated as delimiter.

Possible solutions discussed in the meeting 2022i:

• Handle newlines in evaluate
• Create a new definition of evaluate in the file wordset
• Create a new version of evaluate i.e. multi-line-evaluate

I thought about this problem many times over the years and want to share my view on it.

The real difficulty is once you start to EVALUATE lines like this:

s\" \ \n ( \n ) 1" EVALUATE

By the current standard, the first \ comment will parse and discard the rest of the parse area = the rest of string is not evaluated.

I think it would be preferable if:

• Evaluated strings are interpreted line-by-line
• EVALUATE would make the given string the input source (but NOT the input buffer!)
• REFILL would - similar to what it does for other input sources - make the input buffer the next line from the EVALUATE input source, and return TRUE, if possible.
• ( would have the same behavior as when parsing text files.

1. I expect that systems don't treat newlines in EVALUATEd strings specially (are there systems that do?).

2. I expect that programs don't pass strings with newlines to EVALUATE.

If the latter is true, we could change the requirements as you suggest. But that means that you would have to convince all implementors of standard systems to change their implementation of EVALUATE (and they may be nervous about the possibility of the second point not being true).

It may be easier to just have a new word for interpreting multi-line strings. If you want that word to be standardized, you still have the hard work to convince standards committee members of its value. But if system implementors use such a word as factor of INCLUDED, it may have common practice.

This all makes me wonder what's behind the question by Stephen Pelc that started this thread.

Yes, it would be interesting to hear from Stephen. Personally, I want to achieve following: When loading a text file to RAM and then EVALUATE:ing the buffer, the results would be similar to if the text file was directly INCLUDED.

Since this intent is directly related to file operations, I think it would make sense if this augmented behavior was described in the optional File-Access word set.

Some of the changes would then be straight-forward. For example, for REFILL the standard states in 11.6.2.2125: "When the input source is a text file, attempt to read the next line from the text-input file." One could simply expand this to encompass the EVALUATE string. Same procedure with (. I imagine other changes would be relatively minor.

It was pointed out to me in another thread, that it is probably not right to change REFILL. But I am still hopeful that something good may come out of this discussion.