Enhanced local variable syntax

Interpret S\"

[ RfDs/CfVs | Other proposals ]

Poll Standings

See below for voting instructions.

Systems

[ ] conforms to ANS Forth.: iForth
VFX Forth (Win/OSX/Linux)
Forth 7 cross compilers
SwiftForth
SwiftX
Gforth
[ ] already implements the proposal in full since release [ ].: iForth
VFX Forth (Win/OSX/Linux)
SwiftForth (since 3.0.0 07-Aug-2006)
SwiftX (since 3.2.2 31-Dec-2003)
Gforth (since snapshots)
[ ] implements the proposal in full in a development version.
[ ] will implement the proposal in full in release [ ].
[ ] will implement the proposal in full in some future release.: Forth 7 cross compilers
[ ] There are no plans to implement the proposal in full in [ ].: 4tH [3.62.3]
[ ] will never implement the proposal in full.

Programmers

[ ] I have used (parts of) this proposal in my programs.: Marcel Hendrix
Mitch Bradley
Gerry Jackson
Graham C Smith
Bernd Paysan
[ ] I would use (parts of) this proposal in my programs if the systems I am interested in implemented it.: Mitch Bradley
Gerry Jackson
[ ] I would use (parts of) this proposal in my programs if this proposal was in the Forth standard.: Mitch Bradley
Gerry Jackson
[ ] I would not use (parts of) this proposal in my programs.: Hans Bezemer

Informal Results

Mitch Bradley
I maintain an open source CForth system and the Forth kernel underlying Open Firmware. Both conform to ANS Forth.
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.
Hans Bezemer
This word is only available through libraries and the preprocessor and 4tH programmers should consider it foremost as an aid for porting ANS Forth programs. Most of the proposal is supported, except for \m, which is expanded as 'm' instead of CR/LF. It is the only escape code that standard expands to multiple bytes.
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.

Rationale

Problem

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.

Discussion

There are two possible solutions:

Revise the definition of 6.2.2266 S\" to include interpretation semantics. Alternatively, add a new entry 11.6.2.2266 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".

Solution

Provide a new definition in the FILE EXT word set, 11.6.2.2266 S\" which extends 6.2.2266 S\" by providing interpretation semantics.

Proposal

11.3.4 Transient String Buffers

Replace the exiting text

The list of words using memory in transient regions is extended to include 11.6.1.2165 S". See: 3.3.3.6 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:
S" name1" S" name2" RENAME-FILE
The 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.
S" and S\" may share the same buffers.

The list of words using memory in transient regions is extended to include 11.6.1.2165 S" and 11.6.2.2266 S\". See 3.3.3.6 Other transient regions.

11.6.2 File-Access extension words

11.6.2.2266 S\" FILE EXT s-backslash-quote

Extend the semantics of 6.2.2266 S\" to be:
Interpretation: ( "ccc<quote>" -- c-addr u ): Parse ccc delimited by " (double quote) according to the translation rules given in 6.2.2266 S\". Store the resulting string in a temporary string buffer (c-addr u).
Compilation: ( "ccc<quote>" -- ): Parse ccc delimited by " (double quote) according to the translation rules given in 6.2.2266 S\". Append the run-time semantics given below to the current definition.
Run-time: ( -- c-addr u ): Return a string c-addr u describing the translation of ccc. A program shall not alter the returned string.
See:: 6.2.2266 S\", 11.3.4 Transient String Buffers, 11.6.1.2165 S", A.11.3.4 Transient String Buffers.

11.6.1.2165 S\"

Alter the interpretation semantics of from:

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).

11.6.1.2165 S"

Add 11.6.2.2266 S\" and A.11.3.4 Transient String Buffers to the see list.

11.4.1.1 Implementation-defined options

Adjust the documentation requirements from:

number of string buffers provided (11.6.2.2165 S")
size of string buffer used by 11.6.1.2165 S".

to:

number of temporary string buffers provided (11.3.4 Temporary String Buffers)
size of temporary string buffers (11.3.4 Temporary String Buffers).

3.3.3.4 Text-literal regions

Replace section with:

The text-literal regions, specified by strings compiled with S", S\" and C", may be read-only.
A program shall not store into the text-literal regions created by S", S\" and C" nor into any read-only system variable or read-only transient regions.

Change History

2014-03-11: Minor revisions thanks to comments on comp.lang.forth from Alex McDonald and Steven Pelc.
2014-02-09: Original Text
Gerry Jackson, Bernd Paysan and Peter Knaggs

Voting Instructions

Fill out the appropriate ballot(s) below and mail it/them to <vote@forth200x.org>. Your vote will be published (including your name (without email address) and/or the name of your system) here. You can vote (or change your vote) at any time, and the results will be published here.

Note that you can be both a system implementor and a programmer, so you can submit both kinds of ballots.

Ballot for systems

If you maintain several systems, please mention the systems separately in the ballot. Insert the system name or version between the brackets. Multiple hits for the same system are possible (if they do not conflict).

[ ] conforms to ANS Forth.
[ ] already implements the proposal in full since release [ ].
[ ] implements the proposal in full in a development version.
[ ] will implement the proposal in full in release [ ].
[ ] will implement the proposal in full in some future release.
[ ] There are no plans to implement the proposal in full in [ ].
[ ] will never implement the proposal in full.

If you want to provide information on partial implementation, please do so informally, and I will aggregate this information in some way.

Ballot for programmers

Just mark the statements that are correct for you (e.g., by putting an "x" between the brackets). If some statements are true for some of your programs, but not others, please mark the statements for the dominating class of programs you write.

[ ] I have used (parts of) this proposal in my programs.
[ ] I would use (parts of) this proposal in my programs if the systems I am interested in implemented it.
[ ] I would use (parts of) this proposal in my programs if this proposal was in the Forth standard.
[ ] I would not use (parts of) this proposal in my programs.

If you feel that there is closely related functionality missing from the proposal (especially if you have used that in your programs), make an informal comment, and I will collect these, too. Note that the best time to voice such issues is the RfD stage.