6.1.1360 EVALUATE CORE

( i * x c-addr u -- j * x )

Save the current input source specification. Store minus-one (-1) in SOURCE-ID if it is present. Make the string described by c-addr and u both the input source and input buffer, set >IN to zero, and interpret. When the parse area is empty, restore the prior input source specification. Other stack effects are due to the words EVALUATEd.

Testing:

: GE1 S" 123" ; IMMEDIATE
: GE2 S" 123 1+" ; IMMEDIATE
: GE3 S" : GE4 345 ;" ;
: GE5 EVALUATE ; IMMEDIATE

T{ GE1 EVALUATE -> 123 }T ( TEST EVALUATE IN INTERP. STATE )
T{ GE2 EVALUATE -> 124 }T
T{ GE3 EVALUATE ->     }T
T{ GE4          -> 345 }T

T{ : GE6 GE1 GE5 ; -> }T ( TEST EVALUATE IN COMPILE STATE )
T{ GE6 -> 123 }T
T{ : GE7 GE2 GE5 ; -> }T
T{ GE7 -> 124 }T

See F.9.3.6 for additional test.

ContributeContributions

BerndPaysanavatar of BerndPaysan [17] Check for evaluate SOURCE is the string itself, not a copySuggested Testcase2016-03-21 02:32:54

: GS1 S" SOURCE" ;
T{ GS1 EVALUATE -> GS1 }T

GerryJacksonavatar of GerryJackson

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.

Reply New Version

mcondronavatar of mcondron [103] SOURCE-ID and nesting EVALUATERequest for clarification2019-08-04 15:14:25

Does EVALUATE also need to save the previous SOURCE-ID before setting it to -1? And restore the previous SOURCE-ID after interpretation is complete? Otherwise, how can it be nested, since RESTORE-INPUT requires that the source be the same? Or, should SAVE-INPUT and RESTORE-INPUT also save SOURCE-ID?

AntonErtlavatar of AntonErtl

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.

Reply New Version

StephenPelcavatar of StephenPelc [217] New Line characters in a string passed to EVALUATEExample2021-11-22 17:37:54

How should evaluate handle a string containing two lines of source text separated by a new-line?

GeraldWodniavatar of GeraldWodni

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

AntonErtlavatar of AntonErtl

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.

Closed

GeraldWodniavatar of GeraldWodni

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

JohanKotlinskiavatar of JohanKotlinski

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.

AntonErtlavatar of AntonErtl

  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.

JohanKotlinskiavatar of JohanKotlinski

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.

JohanKotlinskiavatar of JohanKotlinski

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.

Reply New Version