,---------------.
| Contributions |
`---------------´


,------------------------------------------
| 2023-02-07 10:03:28  ruv  wrote:
| requestClarification - Address of the input buffer after RESTORE-INPUT
| see: https://forth-standard.org/standard/core/RESTORE-INPUT#contribution-274
`------------------------------------------
The section [3.3.3.5 Input buffers](https://forth-standard.org/standard/usage#usage:inbuf) 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`.



,------------------------------------------
| 2023-02-07 16:09:01  ruv  wrote:
| comment - About behavior or RESTORE-INPUT
| see: https://forth-standard.org/standard/core/RESTORE-INPUT#contribution-275
`------------------------------------------
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.



,---------.
| Replies |
`---------´


,------------------------------------------
| 2023-01-17 08:36:18  phisheep  replies:
| requestClarification - Seemingly contradictory ambiguous condition?
| see: https://forth-standard.org/standard/doc#reply-945
`------------------------------------------
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"


,------------------------------------------
| 2023-01-17 16:15:55  phisheep  replies:
| comment - 
| see: https://forth-standard.org/standard/doc#reply-946
`------------------------------------------
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."


,------------------------------------------
| 2023-01-17 22:53:04  JohanKotlinski  replies:
| comment - Behavior when no text found
| see: https://forth-standard.org/standard/core/CHAR#reply-947
`------------------------------------------
My Forth does REFILL until it finds a char... does that make sense, or is it better to simply ABORT?