[164] 2020-11-04 17:07:33 LeonWagner wrote:

comment - Typo in stack comment

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 -- )

[r566] 2020-10-31 17:24:02 AntonErtl replies:

proposal - Tick and undefined execution semantics

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.

[r567] 2020-10-31 21:19:03 ruv replies:

proposal - Tick and undefined execution semantics

This [...] fails to make existing state-smart implementations of S" and S\" standard-compliant.

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 codePOSTPONE 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.