[274] 2023-02-07 10:03:28 ruv wrote:

requestClarification - Address of the input buffer after RESTORE-INPUT

The section 3.3.3.5 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.

So, refill may change the the address of the input buffer. And the following line:

:noname ( -- )  source drop  refill drop  postpone \  source drop  <> . ;  execute

may print -1 as well as 0.

So a question arises: may restore-input change the address of the input buffer so it will distinct from the address before save-input?

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

may print -1 as well as 0.

[275] 2023-02-07 16:09:01 ruv wrote:

comment - About behavior or RESTORE-INPUT

It can be not obvious on the first glance from the specifications that:

• restore-input is not obligated to be paired with save-input one-to-one.
• restore-input can 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.

After performing restore-input, the input buffer content should be the same as it was on the time of getting the position.

[r945] 2023-01-17 08:36:18 phisheep replies:

requestClarification - Seemingly contradictory ambiguous condition?

Thank you Anton. I propose we replace the current wording with:

"6.2.1171 DEFER@ 6.2.1175 DEFER! 6.2.0698 ACTION-OF or 6.2.1725 IS applied to a word which was not defined by 6.2.1173 DEFER"

[r946] 2023-01-17 16:15:55 phisheep replies:

comment -

I do not think the documentation requirements are particularly burdensome (having recently gone through the exercise myself), but now that the Exception word set is to be mandatory it could be considerably simplified. I propose replacing the opening paragraph of section 4.1.2 as follows:

"A system shall document the system action taken upon each of the general or specific ambiguous conditions identified in this standard if such action is other than one of the standard THROW codes in table 9.1. See 3.4.4 Possible actions on an ambiguous condition."

[r947] 2023-01-17 22:53:04 JohanKotlinski replies:

comment - Behavior when no text found

My Forth does REFILL until it finds a char... does that make sense, or is it better to simply ABORT?