Digest #123 2020-11-05
The extra 0 at the end of this stack comment looks like a typo: : SET-ORDER ( wid1 ... widn n -0 )
Should be: : SET-ORDER ( wid1 ... widn n -- )
This is at the same time both excessive and fails to make existing state-smart implementations of S" and S" standard-compliant.. E.g., SwiftForth fails
: postpone-s" postpone s" ; : PSQ4 [ postpone-S" XY" ] ; psq4 type psq4 type \ should type "XY", SwiftForth stack-underflows
No ' in sight, so your proposal will not make SwiftForth's S" compliant.
As mentioned elsewhere, a more measured and more precisely targeted approach is to add the same ambiguous condition to S" and S" that allows STATE-smart TO, IS, and ACTION-OF.
This [...] fails to make existing state-smart implementations of
This proposal is not intended to make these implementations standard-compliant. Its intention is to explicitly make non-standard a code like
' S" or
['] S", due to its unclear semantics.
Before that somebody could suppose that such code may take place in a standard program. After that such code is explicitly non-standard. I should have expressed this more clear.
So your example with POSTPONE is not relevant.
If somebody wants to make code
POSTPONE S" non-standard, a separate proposal can be made. But I dislike this idea, since semantics of this code is unambiguous and clear.
By my understanding, to make code
' S" standard-compliant, the standard should define execution semantics for
S". But the code
POSTPONE S" is both standard-compliant and clear without any changes. The single-xt systems, that handle this code in an unexpected way, can be fixed without changing their single-xt property.