/
extension-query.html
383 lines (286 loc) · 13.7 KB
/
extension-query.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
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
<title>Extension queries</title>
<h3>Extension queries</h3>
[ <a href="rfds.html">RfDs/CfVs</a> | <a href="proposals.html">Other proposals</a> ]
<h4>Poll standings</h4>
See <a href="#voting">below</a> for voting instructions.
<h5>Systems</h5>
<pre>
[ ] conforms to ANS Forth.
Gforth
Win32Forth
PFE (Guido Draheim)
iForth (Marcel Hendrix)
[ ] already implements the proposal in full since release [ ].
4th 3.3d R2 (Hans Bezemer)
iForth 3.0
[ ] implements the proposal in full in a development version.
Gforth
[ ] implements the proposal in full non-minimally in a development version.
Gforth
[ ] will implement the proposal in full in release [ ].
Gforth 0.7
4th 3.5b R2 (Hans Bezemer)
[ ] will implement the proposal in full non-minimally in release [ ].
Gforth 0.7
[ ] will implement the proposal in full in some future release.
[ ] will implement the proposal in full non-minimally in some future release.
Win32Forth
There are no plans to implement the proposal in full in [ ].
[ ] will never implement the proposal in full.
PFE
</pre>
<h5>Programmers</h5>
<pre>
[ ] I have used (parts of) this proposal in my programs.
Anton Ertl
[ ] I would use (parts of) this proposal in my programs if the systems
I am interested in implemented it.
David N. Williams
Anton Ertl
Alex McDonald
[ ] I would use (parts of) this proposal in my programs if the systems
I am interested in implemented it non-minimally.
David N. Williams
Anton Ertl
[ ] I would use (parts of) this proposal in my programs if this
proposal was in the Forth standard.
David N. Williams
Anton Ertl
Alex McDonald
[ ] I would not use (parts of) this proposal in my programs.
Hans Bezemer (prefers [DEFINED])
</pre>
<h5>Informal results</h5>
<h4>Change history</h4>
<dl>
<dt>2005-03-16 <dd>No change in the normative section. Made reference
implementation case-insensitive. Added non-normative section on
naming guidelines. Fixed typo.
<dt>2nd RfD 2005-01-17 <dd>No change to the normative section. New,
non-trivial reference implementation. More discussion of "Why not let
ENVIRONMENT? return a flag and true, like for wordset queries?" and
"Why the "X:" prefix?". New sections "Won't there be too many
extension names?", "How about defining a way to query for implementor
extensions?", "Why not just ask for word names with [UNDEFINED]?"
</dl>
<h4>Problem</h4>
How does a program know whether the system it runs on supports one of
the extensions that ran through the RfD/CfV process, so that the
program can implement the extension itself or work around its absence?
<h4>Proposal</h4>
If the string passed to <code>ENVIRONMENT?</code> starts with "X:",
<code>ENVIRONMENT?</code> returns false if the system does not
implement the extension indicated by the query string in full, or if
there is no such extension that has gone to a CfV.
<p>For an extension from the <a href="rfds.html">list of CfVs</a>,
take the linked-to filename, delete the ".html", and prepend "X:" to
construct a query string for the extension.
<p>If the system implements the extension, <code>ENVIRONMENT?</code> may
return true (without additional values) or false.
<h4>Typical Use</h4>
<pre>
S" X:deferred" ENVIRONMENT? 0= [IF]
... \ reference implementation of the deferred words proposal
[THEN]
</pre>
<h4>Remarks</h4>
<h5>Why allow returning false when the system supports the extension?</h5>
Returning false when the system supports the extension will usually be
safer than returning true when the system does not support the
extension; in the former case the program will be slower, or have
degraded features; in the latter case the program will usually fail in
unpredictable ways.
<p>Therefore, systems must not return true for extensions that have
not yet gone to a CfV (the proposal for the extension could still
change).
<p>So, if a system happens to already support the extension, it will
have to report false on queries for the extension at least from the
time when the proposal goes to a CfV until the time that an update of
the system with updated extension queries is released.
<p>Moreover (and possibly more importantly), this feature means that
systems whose implementors have never heard of (or ignore) RfDs and
CfVs will work correctly for extension queries (as long as they don't
support any queries starting with "X:" on their own), so a program
written to cope with this specification will usually work correctly
even on such systems.
<h5>Why not let ENVIRONMENT? return a flag and true, like for wordset
queries?</h5>
This proposal is easier to use. What is the point of returning an
extra flag? "Yes, we have heard of that extension, but no, we have
not implemented it"? That's not a useful information to have; what
should a program do with that information?
<p>Mitch Bradley and Guido Draheim would prefer a wordset-query-like
behaviour, i.e., an additional flag if ENVIRONMENT? returns true.
Richard Borrell would prefer a single flag (i.e., the proposed
behaviour).
<p>With the wordset-query-like behaviour, the typical use above would
look like:
<pre>
S" X:deferred" ENVIRONMENT? dup [IF]
drop
[THEN]
0= [IF]
... \ reference implementation of the deferred words proposal
[THEN]
</pre>
<p>Here are some statistics about the use of ENVIRONMENT? in general
and wordset queries in particular in ANS Forth programs:
<pre>
Program Author ENVIRONMENT? wordset queries
brainless David Kuehling yes no
brew-0_03z9 Robert Epprecht yes no
brew_..._38 Robert Epprecht yes floating-ext
CD16v11 Brad Eckert no no
anagrams Wil Baden no no
pentomino Bruce Hoyt no no
tscp Ian Osgood no no
Gray4 Anton Ertl yes no
garbage-coll Anton Ertl yes no
</pre>
<p>I believe that one of the reason that wordset queries are used so
rarely is that they are so cumbersome to use (that's certainly one of
the reasons that kept me from using it).
<h5>Why the "X:" prefix?</h5>
This will hopefully ensure that there is no naming conflict with any
existing environmental query of any system; it also reserves a part of
the environmental query name space (by requiring a false result for
anything that has not gone to a CfV), without consuming all of it.
<p>If you know of any name conflict of the "X:" prefix with an
existing system and have a better suggestion for a prefix, let me
know.
<p>Bruce McFarling has suggested changing the prefix such that the
query string can be used as a filename on DOS/Windows. However the
prefix can be cut away easily, leading to a filename compatible with
DOS/Windows (if the extension name is compatible), as the <a
href="reference-implementations/extension-query.fs">reference
implementation</a> demonstrates.
<p>Guido Draheim suggested using a suffix, as it has advantages with
input completion. A prefix can also be used to profit with input
completion, and overall this issue does not seem very important.
Prefixes are more traditional for tagging names in programs (while
suffixes are used for file names).
<h5>What about extension proposals that have not (yet) gone to a
CfV?</h5>
If you want to introduce queries for them, do it with a different
prefix.
<h5>Why not include extension proposals that have not (yet) gone to a
CfV?</h5>
They may still change before they go to a CfV, so it would not be
clear if the system and the querying program refer to the same
proposal.
<h5>Won't there be too many extension names?</h5>
Guido Draheim thinks that we will see many backwards-compatible
revisions of proposals, so the number of extension names that should
be known around for a the extensions would be a problem (since the nth
revision would satisfy the requirements of revision 1-n, and thus n
names would have to be kept around).
<p>One way to deal with this would be to use a consistent naming
scheme for backwards-compatible extensions: deferred, deferred-2,
deferred-3 etc. Then the system just needs to store the base name and
the current revision number, and can check with a little code whether
the queried-for extension is supported.
<p>Keeping this naming scheme would be the responsibility of the
person who maintains the list of CfVs. (It's not the responsibility
of the system implementor and therefore not in the normative part of
this proposal).
<h5>How about defining a way to query for implementor extensions?</h5>
Guido Draheim suggested this. With this one system implementor could
formally define an extension, and another system could adopt that
extension, and programs could query for this extension.
<p>Doing this would require reserving some part of the ENVIRONMENT?
name space for implementor-extension queries, with each query having
an implementor part, and an extension name. A naming authority would
assign implementor part names to implementors, and the implementor
would assign extension part names. (Actually the implementor
could use it for arbitrary queries, not just extension queries).
<p>I am not convinced that there is enough demand for that. In any
case, I would like to see it handled in a separate RfD/CfV.
<h5>Why not just ask for word names with [UNDEFINED]?</h5>
<p>Hans Bezemer and Albert van der Horst favour this approach.
<p>That only tells whether a word exists in the system, but not how it
behaves.
<p>It would also require asking separately for each word. And for
on-demand loading, it would require organizing each word separately.
Lots of effort for the programmer and the system implementor.
<h5>Guidelines for extension names</h5>
Extension names should limited to 29 characters (excluding the "X:"
prefix), so they can be stored into a wordlist systems with 31-char
names.
<p>The names of the extension queries (excluding the "X:" prefix) and
the file names of the reference implementations should be lower case,
so that the reference implementation of extension queries works on
case-sensitive file systems (most Forth systems and the reference
implementation match extension-query names case-insensitively, but
making that standard is another RfD).
<p>The names of the extension queries (excluding the "X:" prefix)
should only contain printable ASCII characters that are allowed in all
common file systems; it's probably best to just use alphanumeric
characters and the "-".
<h5>Implementation and Tests</h5>
<ul>
<li><a href="reference-implementations/extension-query.fs">Reference
implementation</a>; to make it useful, you should also download and
unpack <a href="forth200x-code.zip">forth200x-code.zip</a>, containing a
directory of reference implementations of voted-on extensions (if
available).
<li><a href="tests/extension-query.fs">Tests</a>
</ul>
<h4>Experience</h4>
All ANS Forth systems I know implement this proposal in a minimal way
(answer all queries with false). None implement it in a non-minimal
way. No programs have used the proposal yet.
<h4>Comments</h4>
<h4><a name="voting">Voting instructions</a></h4>
Fill out the appropriate ballot(s) below and mail it/them to me
<anton@mips.complang.tuwien.ac.at>. 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 by
mailing to me, 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.
<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).
<p>Since most ANS Forth systems already support this proposal in full
in a minimal way (i.e., they return false on every extension query),
this ballot also asks for non-minimal support.
<p>Note that for this proposal non-implementation means that you
reserve the right to answer "X:" queries with true even if you do not
implement the queried-for extension. If the system answers the query
with false, it supports the proposal in full in a minimal way.
<pre>
[ ] conforms to ANS Forth.
[ ] already implements the proposal in full since release [ ].
[ ] implements the proposal in full in a development version.
[ ] implements the proposal in full non-minimally in a development version.
[ ] will implement the proposal in full in release [ ].
[ ] will implement the proposal in full non-minimally in release [ ].
[ ] will implement the proposal in full in some future release.
[ ] will implement the proposal in full non-minimally in some future release.
There are no plans to implement the proposal in full in [ ].
[ ] will never implement the proposal in full.
</pre>
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.
<pre>
[ ] 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 the systems
I am interested in implemented it non-minimally.
[ ] 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.
</pre>
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.
<hr><a href="http://www.complang.tuwien.ac.at/anton/">Anton Ertl</a>