11.6.1.2165 S" s-quote FILE

Extend the semantics of 6.1.2165 S" to be:

Interpretation:

( "ccc<quote>" -- c-addr u )

Parse ccc delimited by " (double quote). Store the resulting string in a transient buffer c-addr u.

Compilation:

( "ccc<quote>" -- )

Parse ccc delimited by " (double quote). Append the run-time semantics given below to the current definition.

Run-time:

( -- c-addr u )

Return c-addr and u that describe a string consisting of the characters ccc.

See:

Rationale:

Typical use: ... S" ccc" ...

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:

T{ S" A String"2DROP -> }T    \ There is no space between the " and 2DROP

ContributeContributions

UlrichHoffmannavatar of UlrichHoffmann [65] S( "Request for Discussion" (revised 2018-08-16)Proposal2018-08-17 16:27:53

This contribution has been moved to the proposal section.

ruvavatar of ruv

This reply has been moved to the proposal section.

ruvavatar of ruv

This reply has been moved to the proposal section.

StephenPelcavatar of StephenPelc

This reply has been moved to the proposal section.

BerndPaysanavatar of BerndPaysan

This reply has been moved to the proposal section.

BerndPaysanavatar of BerndPaysan

This reply has been moved to the proposal section.

AntonErtlavatar of AntonErtl

This reply has been moved to the proposal section.

UlrichHoffmannavatar of UlrichHoffmann

This reply has been moved to the proposal section.
Retracted
Reply New Version

ruvavatar of 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.

BerndPaysanavatar of 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.

Closed

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

Open
Reply New Version