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


,------------------------------------------
| 2020-11-04 17:07:33  LeonWagner  wrote:
| comment - Typo in stack comment
| see: https://forth-standard.org/standard/search/SET-ORDER#contribution-164
`------------------------------------------
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 -- )




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


,------------------------------------------
| 2020-10-31 17:24:02  AntonErtl  replies:
| proposal - Tick and undefined execution semantics
| see: https://forth-standard.org/proposals/tick-and-undefined-execution-semantics#reply-566
`------------------------------------------
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.


,------------------------------------------
| 2020-10-31 21:19:03  ruv  replies:
| proposal - Tick and undefined execution semantics
| see: https://forth-standard.org/proposals/tick-and-undefined-execution-semantics#reply-567
`------------------------------------------
> 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 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.