Digest #210 2023-02-16
In presence of the
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
- (if n <> 0) "restore the input source specification in use before the corresponding CATCH" (emphasis added)
While the specification for
- "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),
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.
The ( in +n -- ) part is wrong. It's either ( nx +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 -- ).
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.
I suppose that i=n follows from the statement "Remove n+1 items from the data stack".
( 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
SET-ORDER have the same problem.
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. Maybe it's even better to use the data type
u instead of
n for these words.
And then a correction for
GET-ORDER ( -- wid_n ... wid_1 n | 0 )
SET-ORDER ( wid_n ... wid_1 n | 0 | -1 -- )
that n>0 via
that n ≥ 0 via
+n data type.
N>Ron SwiftForth shows two uses, both after
SAVE-INPUTand likewise both usese of
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.
See also some thoughts on this subject in the comment in 2019 by Anton.