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


,------------------------------------------
| 2023-02-15 22:50:52  ruv  wrote:
| comment - Input source after THROW
| see: https://forth-standard.org/standard/exception/THROW#contribution-283
`------------------------------------------
In presence of the `save-input` and `restore-input` words, it could appear that `throw` should restore the **state** of the input source as it was before execution of the corresponding `catch`, **due to similar wording**.

But actually the specification only requires that if a throw code is non zero, the input source is the same before and after execution of `catch`. But the state of this input source **may** be changed.

Namely, the specification for [`THROW`](#) says:
- (if *n* <> 0) "restore the input source specification **in use** before the corresponding CATCH"  (emphasis added)

While the specification for [`RESTORE-INPUT`](https://forth-standard.org/standard/core/RESTORE-INPUT) says:
- "restore the input source specification **to the state** described by..."   (emphasis added)


If the state of the input source were to be restored, the following test would show the same line "source: test" twice:
```
: test [: cr ." source: " source type cr ." next line: " refill cr . cr abort ;] catch drop ." source: " source type cr  postpone \ ;
test
\ some other line
```

NB: the state of the input source can be only changed via `>in` (directly or indirectly), `refill`, and `restore-input`. No other way to change this state for a standard program.

Please correct me if I'm wrong somewhere. Otherwise, the wording should reflect this nuance more explicit, I think.



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


,------------------------------------------
| 2023-02-15 11:39:35  AntonErtl  replies:
| comment - Bad Stack Notation?
| see: https://forth-standard.org/standard/tools/NtoR#reply-955
`------------------------------------------
The ( i*n +n -- ) part is wrong.  It's either ( n*x +n -- ) or, if we say that i*x just means an arbitrary number of (i.e., not necessarily i)  stack items, then it should be ( x1 ... xn +n -- ).


,------------------------------------------
| 2023-02-15 11:53:32  AntonErtl  replies:
| requestClarification - Is data stack required?
| see: https://forth-standard.org/standard/core/SAVE-INPUT#reply-956
`------------------------------------------
Yes, it's a requirement.  However, given that the other requirements (guarantees to programs) are very weak, you do not need to put a lot of data on the data stack (at least for a minimal implementation of SAVE-INPUT).

Those who support N>R NR> told me that SAVE-INPUT N>R ... NR> RESTORE-INPUT is a usage that motivates N>R NR>.  WHERE N>R on SwiftForth shows two uses, both after SAVE-INPUT and likewise both usese of NR> are before RESTORE-INPUT.


,------------------------------------------
| 2023-02-15 20:40:59  ruv  replies:
| comment - Bad Stack Notation?
| see: https://forth-standard.org/standard/tools/NtoR#reply-957
`------------------------------------------
I suppose that *i=n* follows from the statement "Remove *n*+1 items from the data stack".

The diagram `( x1 ... xn +n -- )` seems incorrect for the case *n*=0, since it starts from 1, and implies at least one *x*. Although, the diagrams for `GET-ORDER` and `SET-ORDER` have the same problem.

Concerning order of numbering, in other similar cases it's ascending towards the bottom of the stack (see [ROLL](https://forth-standard.org/standard/core/ROLL) or [GET-ORDER](https://forth-standard.org/standard/search/GET-ORDER)).

So, taking into account that in all other cases, if the number of items is known beforehand in run-time then the notation `( x_[n] x_[n-1] ...` is used (i.e., not `i*x`),  a better variant could be:

- `N>R (  x_n ... x_1 n | 0 -- )`
- `NR> ( -- x_n ... x_1 n | 0 )`

It's obvious that *n*>1, so it's not necessary to indicate that *n*>0 via `+n` [data type](https://forth-standard.org/standard/usage#table:datatypes). Maybe it's even better to use the data type `u` instead of `n` for these words.

And then a correction for `GET-ORDER` and `SET-ORDER`:
- `GET-ORDER ( -- wid_n ... wid_1 n | 0 )`
- `SET-ORDER ( wid_n ... wid_1 n | 0 | -1 -- )`



,------------------------------------------
| 2023-02-15 21:16:08  ruv  replies:
| comment - Bad Stack Notation?
| see: https://forth-standard.org/standard/tools/NtoR#reply-958
`------------------------------------------
> that *n*>0 via `+n` data type.

Correction: 

that _n_ __≥__ 0 via `+n` data type.



,------------------------------------------
| 2023-02-15 22:07:23  ruv  replies:
| requestClarification - Is data stack required?
| see: https://forth-standard.org/standard/core/SAVE-INPUT#reply-959
`------------------------------------------
>  `N>R` on SwiftForth shows two uses, both after `SAVE-INPUT` and likewise both usese of `NR>` are before `RESTORE-INPUT`.

BTW, in SwiftForth `RESTORE-INPUT` is used on a different input source. A standard program cannot use them in such a manner due to an ambiguous condition, which "exists if the input source represented by the arguments is not the same as the current input source".

Also, a SwiftForth version 3.11.6 peculiar (probably not only its) is that `RESTORE-INPUT` returns 0 (success) when it actually does not restore **the state** of the input source — e.g., in the case of keyboard. In this case it restores the **position**, but not the **content** of the input buffer. According to the specification, it shall restore nothing and return fail (`-1`), if it cannot restore the state of the input source.



,------------------------------------------
| 2023-02-15 23:09:47  ruv  replies:
| comment - Input source after THROW
| see: https://forth-standard.org/standard/exception/THROW#reply-960
`------------------------------------------
See also some thoughts on this subject in the [comment in 2019](https://forth-standard.org/standard/exception/CATCH#reply-265) by Anton.