Digest #153 2021-05-19

Contributions

[201] 2021-05-18 01:22:07 ruv wrote:

requestClarification - Implementation for «S"» via the immediacy mechanism

Could anybody confirm that my implementation 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, raw message) 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 says that when interpreting, ' xyz EXECUTE is equivalent to xyz.

I proved in length (in news:rpiir0$lqd$1@dont-email.me, thread, raw message) 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.