EVALUATE

( 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 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 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 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
Reply New Version