[ RfDs/CfVs | Other proposals ]
I do not currently implement S\" as specified, but I do have a similar mechanism - something like 15 years old - for handling escaped strings, and it does work in both interpret and compile state.
So, if I ever switch over to S\", it will definitely work in interpret state, hence I support the proposal.
In my experience supporting programmers who are trying to use Forth, differences between compilation and interpretation syntax are a major source of problems, especially among novices (and novices are especially important because any roadblocks they face decreases the chance that they will stick with Forth). So I am in favor of making interpretation and compilation as similar as possible.
Due to 4tH's architecture it has ALWAYS been available in 'interpretation' mode (4tH doesn't have a 'real' equivalent to that state - it defined there as 'outside a definition'). The code is expanded at runtime - not compile time.
In 4tH there are plenty of alternatives to resolve the kind of problems where S\" is the ANS Forth solution. Therefore it is not part of the core. I never used it myself - apart from programs to test the current implementation.
S" is extended in the File-Access word set to be usable in interpretation mode.
S\" is a sister word to S" but is not extended in the same way in the File-Access word set.
It seems to me that S\" is just as useful as S" in interpretation mode.
There are two possible solutions:
Revise the definition of 6.2.2266 S\" to include interpretation semantics. Alternatively, add a new entry 220.127.116.116 S\" which adds the interpretation action, in the same manner as S".
The interpretation semantics of S" are provided in a separate definition, so that small systems are not required to implement it. The same can be said of the interpretation semantics for S\". Thus, we propose taking the second option, and provide a new definition of S\" in the FILE word set to provide the interpretation semantics.
This brings us to the question of which buffer should S\" use. As S\" is intended as an extension to S" it would make sense to allow S\" to use the same buffers as S". The description of the buffer lifetime in S" will need to be revised.
The number of available buffers is defined as "At least one". As a number of FILE words require two strings, this would be the right time to change this to "at least two".
SolutionProvide a new definition in the FILE EXT word set, 18.104.22.1686 S\" which extends 6.2.2266 S\" by providing interpretation semantics.
Proposal11.3.4 Transient String Buffers Replace the exiting text
The list of words using memory in transient regions is extended to include 22.214.171.1245 S". See: 126.96.36.199 Other transient regions.with
The system provides transient buffers for S" and S\" strings. These buffers shall be no less than 80 characters in length, and there shall be at least two buffers. The system should be able to store two strings defined by sequential use of S" or S\".A.11.3.4 Transient String Buffers Add a new section with the text
Additional transient buffers are provided for use by S" and S\". The buffers should be able to store two consecutive strings, thus allowing the command line:11.6.2 File-Access extension wordsThe buffers may be implemented in a circular arrangement, where a string is placed into the next available buffer. When there are no buffers available, the oldest buffer is overwritten.
Parse ccc delimited by " (double quote). Store the resulting string c-addr u at a temporary location. The maximum length of the temporary buffer is implementation-dependent but shall be no less than 80 characters. Subsequent uses of S" may overwrite the temporary buffer. At least one such buffer shall be provided.to:
Parse ccc delimited by " (double quote). Store the resulting string in a temporary string buffer (c-addr u).188.8.131.525 S" Add 184.108.40.2066 S\" and A.11.3.4 Transient String Buffers to the see list. 220.127.116.11 Implementation-defined options Adjust the documentation requirements from:
The text-literal regions, specified by strings compiled with S", S\" and C", may be read-only.
comp.lang.forthfrom Alex McDonald and Steven Pelc.
Note that you can be both a system implementor and a programmer, so you can submit both kinds of ballots.