forked from Forth-Standard/forth200x
/
s-escape-quote.html
334 lines (301 loc) · 11.9 KB
/
s-escape-quote.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
<html>
<head>
<title>Enhanced local variable syntax </title>
<style type="text/css">
ol li { margin-left: -1em; }
.item { width: 5em; }
ul.results { margin-left: 0em; padding-left: 20px; }
ul.results li { margin-bottom: 1ex; }
ul.results li:first-line { font-weight: bold; }
.history dd { margin-bottom: 1ex; }
.def dd { margin-bottom: 2ex; }
div.glossary { text-align: center; margin-top: 1ex; }
.glossary span.def { float: left; }
.glossary span.wordset { float: right; }
</style>
</head>
<body>
<h3>Interpret S\"</h3>
<p>
[ <a href="rfds.html">RfDs/CfVs</a> | <a href="proposals.html">Other proposals</a> ]
</p>
<h3>Poll Standings</h3>
See <a href="#voting">below</a> for voting instructions.
<h4>Systems</h4>
<dl>
<dt> [ ] conforms to ANS Forth.</dt>
<dd>iForth<br/>
VFX Forth (Win/OSX/Linux)<br/>
Forth 7 cross compilers<br />
SwiftForth<br />
SwiftX<br />
Gforth
</dd>
<dt> [ ] already implements the proposal in full since release [ ].</dt>
<dd>iForth<br/>
VFX Forth (Win/OSX/Linux)<br />
SwiftForth (since 3.0.0 07-Aug-2006)<br />
SwiftX (since 3.2.2 31-Dec-2003)<br />
Gforth (since snapshots)
</dd>
<dt> [ ] implements the proposal in full in a development version.</dt>
<dt> [ ] will implement the proposal in full in release [ ].</dt>
<dt> [ ] will implement the proposal in full in some future release.</dt>
<dd>Forth 7 cross compilers</dd>
<dt> [ ] There are no plans to implement the proposal in full in [ ].
<dd>4tH [3.62.3]</dd>
</dt>
<dt> [ ] will never implement the proposal in full.
</dl>
<h4>Programmers</h4>
<dl>
<dt> [ ] I have used (parts of) this proposal in my programs.</dt>
<dd>Marcel Hendrix<br/>
Mitch Bradley<br/>
Gerry Jackson<br />
Graham C Smith<br />
Bernd Paysan
</dd>
<dt> [ ] I would use (parts of) this proposal in my programs if the systems I am interested in implemented it.</dt>
<dd>Mitch Bradley<br/>
Gerry Jackson
</dd>
<dt> [ ] I would use (parts of) this proposal in my programs if this proposal was in the Forth standard.</dt>
<dd>Mitch Bradley<br/>
Gerry Jackson
</dd>
<dt> [ ] I would not use (parts of) this proposal in my programs.</dt>
<dd> Hans Bezemer
</dd>
</dl>
<h4>Informal Results</h4>
<ul class="results">
<li>Mitch Bradley<br/>
I maintain an open source CForth system and the Forth kernel underlying
Open Firmware. Both conform to ANS Forth.
<p>
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.
</p><p>
So, if I ever switch over to S\", it will definitely work in interpret
state, hence I support the proposal.
</p><p>
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.
</p>
</li>
<li>Hans Bezemer<br/>
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.
<p>
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.
</p><p>
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.
</p>
</ul>
<h2>Rationale</h2>
<table width="500"><tr><td>
<h3>Problem</h3>
<p>
S" is extended in the File-Access word set to be usable in
interpretation mode.
</p><p>
S\" is a sister word to S" but is not extended in the same
way in the File-Access word set.
</p><p>
It seems to me that S\" is just as useful as S" in interpretation mode.
</p>
<h3>Discussion</h3>
<p>There are two possible solutions:</p>
<p>
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".
</p><p>
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.
</p><p>
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.
</p><p>
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".
</p>
<h3>Solution</h3>
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.
<h3>Proposal</h3>
<strong>11.3.4 Transient String Buffers</strong><p/>
Replace the exiting text
<blockquote>
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.
</blockquote>
with
<blockquote>
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\".
</blockquote>
<strong>A.11.3.4 Transient String Buffers</strong><p/>
Add a new section with the text
<blockquote>
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:
<blockquote>
<code>S" name1" S" name2" RENAME-FILE</code>
</blockquote>
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.
<p>S" and S\" may share the same buffers.</p>
<p>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.</p>
</blockquote>
<strong>11.6.2 File-Access extension words</strong>
<div class="glossary">
<span class="def">11.6.2.2266 <code>S\"</code></span>
<span class="wordset">FILE EXT</span>
s-backslash-quote
</div>
<dl class="def">
<dd>Extend the semantics of 6.2.2266 S\" to be:</dd>
<dt>Interpretation: ( <em>"ccc<quote>"</em> -- <em>c-addr u</em> )</dt>
<dd>Parse <em>ccc</em> delimited by " (double quote) according to the
translation rules given in 6.2.2266 S\". Store the resulting
string in a temporary string buffer (<em>c-addr u</em>).
</dd>
<dt>Compilation: ( <em>"ccc<quote>"</em> -- )</dt>
<dd>Parse <em>ccc</em> 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.
</dd>
<dt>Run-time: ( -- <em>c-addr u</em> )</dt>
<dd>Return a string <em>c-addr u</em> describing the translation of <em>ccc</em>.
A program shall not alter the returned string.
</dd>
<dt>See:</dt>
<dd>6.2.2266 S\",
11.3.4 Transient String Buffers,
11.6.1.2165 S",
A.11.3.4 Transient String Buffers.
</dd>
</dl>
<strong>11.6.1.2165 S\"</strong><p/>
Alter the interpretation semantics of from:
<blockquote>
Parse <em>ccc</em> delimited by " (double quote). Store the resulting
string <em>c-addr u</em> 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.
</blockquote>
to:
<blockquote>
Parse <em>ccc</em> delimited by " (double quote). Store the
resulting string in a temporary string buffer (<em>c-addr u</em>).
</blockquote>
<strong>11.6.1.2165 S"</strong><p/>
Add 11.6.2.2266 S\" and A.11.3.4 Transient String Buffers to the
see list.
<p/>
<strong>11.4.1.1 Implementation-defined options</strong><p/>
Adjust the documentation requirements from:
<ul>
<li>number of string buffers provided (11.6.2.2165 S")</li>
<li>size of string buffer used by 11.6.1.2165 S".</li>
</ul>
to:
<ul>
<li>number of temporary string buffers provided (11.3.4 Temporary String Buffers)</li>
<li>size of temporary string buffers (11.3.4 Temporary String Buffers).</li>
</ul>
<strong>3.3.3.4 Text-literal regions</strong><p/>
Replace section with:
<blockquote>
The text-literal regions, specified by strings compiled with
S", S\" and C", may be read-only.
<p>
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.</p>
</blockquote>
</td></tr></table>
<h3>Change History</h3>
<dl class="history">
<dt>2014-03-11</dt><dd>
Minor revisions thanks to comments on <code>comp.lang.forth</code>
from Alex McDonald and Steven Pelc.</dd>
<dt>2014-02-09</dt><dd>
Original Text<br />
Gerry Jackson, Bernd Paysan and Peter Knaggs
</dd>
</dl>
<a name="voting"><h3>Voting Instructions</h3></a>
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.
<p>
Note that you can be both a system implementor and a programmer, so
you can submit both kinds of ballots.
</p>
<h4>Ballot for systems</h4>
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).
<dl>
<dt>[ ] conforms to ANS Forth. </dt>
<dt>[ ] already implements the proposal in full since release [ ]. </dt>
<dt>[ ] implements the proposal in full in a development version. </dt>
<dt>[ ] will implement the proposal in full in release [ ]. </dt>
<dt>[ ] will implement the proposal in full in some future release. </dt>
<dt>[ ] There are no plans to implement the proposal in full in [ ]. </dt>
<dt>[ ] will never implement the proposal in full. </dt>
</dl>
If you want to provide information on partial implementation, please do
so informally, and I will aggregate this information in some way.
<h4>Ballot for programmers</h4>
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.
<dl>
<dt>[ ] I have used (parts of) this proposal in my programs.</dt>
<dt>[ ] I would use (parts of) this proposal in my programs if the systems
I am interested in implemented it.</dt>
<dt>[ ] I would use (parts of) this proposal in my programs if this
proposal was in the Forth standard.</dt>
<dt>[ ] I would not use (parts of) this proposal in my programs.</dt>
</dl>
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.
</body>
</html>