11.6.1.2165 S" s-quote FILE
Interpretation:
Parse ccc delimited by " (double quote). Store
the resulting string in a transient buffer c-addr u.
Compilation:
Parse ccc delimited by " (double quote). Append
the run-time semantics given below to the current definition.
Run-time:
Return c-addr and u that describe a string consisting of the characters ccc.
See:
11.6.2.2266 S\", A.11.3.4 Other transient regions, A.11.6.1.2165 S".
Rationale:
" ...
The interpretation semantics for S" are intended to provide a simple mechanism for entering a string in the interpretation state. Since an implementation may choose to provide only one buffer for interpreted strings, an interpreted string is subject to being overwritten by the next execution of S" in interpretation state. It is intended that no standard words other than S" should in themselves cause the interpreted string to be overwritten. However, since words such as EVALUATE, LOAD, INCLUDE-FILE and INCLUDED can result in the interpretation of arbitrary text, possibly including instances of S", the interpreted string may be invalidated by some uses of these words.
When the possibility of overwriting a string can arise, it is prudent to copy the string to a "safe" buffer allocated by the application.
Testing:
ContributeContributions
UlrichHoffmann
[65] S( "Request for Discussion" (revised 2018-08-16)Proposal2018-08-17 16:27:53
ruv
ruv
StephenPelc
BerndPaysan
BerndPaysan
AntonErtl
UlrichHoffmann
ruv
[201] Implementation for «S"» via the immediacy mechanismRequest for clarification2021-05-18 01:22:07
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.
BerndPaysan
On behalf of the committee,
The original 94 TC very likely meant this (state-smart S") to be standard, but failed to specify it that way.
ruv
The original 94 TC very likely meant this (state-smart
S") to be standard, but failed to specify it that way.
Does this answer imply that my implementation has conflict with the normative parts of the Forth-94 standard?
If yes, could you please show such a conflict?
(I reopen this request since my question still remains)