6.2.2148 RESTORE-INPUT CORE EXT
Attempt to restore the input source specification to the state described by x1 through xn. flag is true if the input source specification cannot be so restored.
An ambiguous condition exists if the input source represented by the arguments is not the same as the current input source.
ruv  Address of the input buffer after RESTORE-INPUTRequest for clarification2023-02-07 10:03:28
The section 18.104.22.168 Input buffers says:
The address and length returned by
SOURCE, the string returned by
PARSE, and directly computed input-buffer addresses are valid only until the text interpreter does I/O to refill the input buffer or the input source is changed.
refill may change the the address of the input buffer. And the following line:
:noname ( -- ) source drop refill drop postpone \ source drop <> . ; execute
-1 as well as
So a question arises: may
restore-input change the address of the input buffer so it will distinct from the address before
I think, it may, since
restore-input can do I/O. Hence, we should conclude that a particular state of the input buffer does not include the address where this buffer is located.
And it means that the fragment:
:noname ( -- ) source drop save-input refill drop restore-input abort" cannot restore input" source drop <> . ; execute
-1 as well as
ruv  About behavior or RESTORE-INPUTComment2023-02-07 16:09:01
It can be not obvious on the first glance from the specifications that:
restore-inputis not obligated to be paired with
restore-inputcan be applied one time, several times (more than 1), or even never to the same input source specification.
The input source specification, which
save-input returns, is a kind of a position in the input source, and a program may use this position zero, one, or more times within this input source. And this position should be a valid parameter all the time while the program has access to the corresponding input source.
restore-input, the input buffer content should be the same as it was on the time of getting the position.