Digest #210 2023-02-16
Contributions
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 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
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".
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 or 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. 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 -- )
that n>0 via
+ndata type.
Correction:
that n ≥ 0 via +n data type.
N>Ron SwiftForth shows two uses, both afterSAVE-INPUTand likewise both usese ofNR>are beforeRESTORE-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.
See also some thoughts on this subject in the comment in 2019 by Anton.