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


,------------------------------------------
| 2021-05-18 01:22:07  ruv  wrote:
| requestClarification - Implementation for «S"» via the immediacy mechanism
| see: https://forth-standard.org/standard/file/Sq#contribution-201
`------------------------------------------
Could anybody confirm that [my implementation](https://gist.github.com/ruv/21e7b4d0693dce587adeecb824e9c5aa) for FILE `S"` is standard-compliant,
or prove by the normative texts that it isn't compliant  (according to Forth-94 or Forth-2012)?

The implementation is the following:
```
[undefined] slit, [if]  : slit,   postpone sliteral ;  [then]
: carbon-slit ( c-addr1 u -- c-addr2 u ) dup allocate throw swap 2dup 2>r cmove 2r> ;
: tt-slit ( c-addr u -- | c-addr u -- c-addr2 u ) state @ if slit, exit then carbon-slit ;
: s" [char] " parse tt-slit ; immediate
```
(Take into account that my `postpone` correctly works for this `s"`).


Anton claimed (in news:`2020Oct31.163659@mips.complang.tuwien.ac.at`, [thread](https://groups.google.com/g/comp.lang.forth/c/GyzL0wIENUw/m/C-5z9XAVAQAJ), [raw message](https://groups.google.com/forum/message/raw?msg=comp.lang.forth/GyzL0wIENUw/C-5z9XAVAQAJ/))
that this implementation is not compliant since the following test fails (I slightly rewrite the original test to make it more formal):
```
: [execute] execute ; immediate
t{  0 ' s" ] [execute] bla" [   dup [if] s" bla" compare 0=  nip [then]  -> true }t
```

This test checks (in a safely manner) that performing the execution semantics for `s"` in compilation state is equivalent to performing these execution semantics in interpretation state. By Anton's view, they should be equivalent since [6.1.0070 Tick](https://forth-standard.org/standard/core/Tick) says that 
when interpreting, `' xyz EXECUTE` is equivalent to `xyz`.

I proved in length (in news:`rpiir0$lqd$1@dont-email.me`, [thread](https://groups.google.com/g/comp.lang.forth/c/GyzL0wIENUw/m/80RKi7PhAgAJ), [raw message](https://groups.google.com/forum/message/raw?msg=comp.lang.forth/GyzL0wIENUw/80RKi7PhAgAJ/))
that this test is incorrect since it tests undefined behavior.

Briefly, it's obvious that in the general case, performing execution semantics in compilation state may be inequivalent to performing these execution semantics in interpretation state. And we don't have any ground to say that they should be equivalent in the case of the `s"` word, since the execution semantics for `s"` are not specified by the standard.