/
defined.html
222 lines (173 loc) · 7.67 KB
/
defined.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
<title>[DEFINED] and [UNDEFINED] proposal</title>
<h3><a name="deferred">[DEFINED] and [UNDEFINED]</a></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.
VFX Forth for Windows, DOS, ... (Stephen Pelc)
Forth 6 cross compilers (Stephen Pelc)
Gforth (Anton Ertl)
Win32Forth (Alex McDonald)
BigForth (Bernd Paysan)
iForth (Marcel Hendrix)
SwiftForth and SwiftX (Elizabeth Rather)
PFE (Guido Draheim)
[ ] already implements the proposal in full since release [ ]:
VFX Forth 3.2 for Windows, DOS, ... (Stephen Pelc)
Forth 6 cross compilers 3.2 (Stephen Pelc)
Gforth 0.6 (Anton Ertl)
Win32Forth 4 (Alex McDonald)
iForth 1.1 (Marcel Hendrix)
SwiftForth and SwiftX 1.0 (Elizabeth Rather)
4th 3.4e (Hans Bezemer)
PFE 30.11 (Oct. 2000)
[ ] 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 [ ].
BigForth
[ ] will never implement the proposal in full:
</pre>
<h5>Programmers</h5>
<pre>
[ ] I have used (parts of) this proposal in my programs:
Stephen Pelc
Alex McDonald
David N. Williams
Robert Epprecht
Richard Borrell
Bruce McFarling
Marcel Hendrix
Hans Bezemer
[ ] I would use (parts of) this proposal in my programs if the systems
I am interested in implemented it:
Chris Walton
David N. Williams
Marcel Hendrix
[ ] I would use (parts of) this proposal in my programs if this
proposal was in the Forth standard:
Alex McDonald
Chris Walton
David N. Williams
Bernd Paysan
Marcel Hendrix
[ ] I would not use (parts of) this proposal in my programs.
</pre>
<h5>Informal results</h5>
In Win32Forth, local names return TRUE from [DEFINED] when in scope;
[DEFINED] returns false for methods (in the OO extension); for Windows
API names, the result depends on the Win32Forth version and whether
the name has already been used. For details, see <a
href="http://groups.google.at/group/comp.lang.forth/msg/456531063dc8ca03?dmode=source"><434270FC.4000408@btopenworld.com></a>
<p>BigForth has [IFDEF] and [IFUNDEF] instead.
<h4>Proposal</h4>
(will be reformatted in HTML later)
<pre>
Problem
The need for a standard word to find whether some Forth word has
already been defined and is available. The usefulness of such
words is indicated by how commonly they are available in one
form or another (see 'Experience' below). The greatest value is
probably for code expected to be run on different systems which
may differ in the words they provide.
Proposal
[DEFINED] ( "<spaces>string<space>" -- flag ) SEARCH EXT
Parse space-delimited string. Return true flag if string is the
name of a word found in the current search order; otherwise return
false flag. An Immediate word.
[UNDEFINED] ( "<spaces>string<space>" -- flag SEARCH EXT
Parse space-delimited string. Return false flag if string is the
name of a word found in the current search order; otherwise return
true flag. An Immediate word.
Remarks
The intent of the proposal is to establish a standard spelling for
a word widely used and commonly available, but with varying
orthography. The spelling proposed here is one of the common ones,
but there are a number of others.
It could be argued that adding to the Standard words so easily
defined (see below) just adds unnecessary bloat. The counter
argument is the convenience for someone writing code that may be
used on several different systems in knowing what name is used
for a common capability that may well be present.
Only one of the two is needed, since the other is obtained by
postpending 0=. My guess would be that [UNDEFINED] is used more
often, as in the Typical use below. But if a system has room to
provide one, why not both?
Reference implementation
: [DEFINED] BL WORD FIND NIP 0<> ; IMMEDIATE
: [UNDEFINED] BL WORD FIND NIP 0= ; IMMEDIATE
Typical use
[UNDEFINED] 4DUP [IF] : 4DUP 2OVER 2OVER ; [THEN]
Experience
Common as dirt. With one spelling or another, the capability
is provided in Wil Baden's Comus and toolkits and E. Rather's
Forth Programmer's Handbook. Versions are included in Gforth,
PFE, Bigforth and Win32Forth. I believe it is present in both
SwiftForth and VFX Forth for Windows, and Stephen Pelc says it
is part of the cross compiler draft standard. I'm sure there
are more.
The functionality is almost always equivalent to what is proposed
here, so it would seem that conforming to a standard spelling
should not be difficult for system developers.
Comments
(Summarized briefly. Details and attributions can be seen in the
archives of postings to groups.yahoo.com/group/forth200x and
comp.lang.forth. I find there was also a discussion of these and
related words in comp.lang.forth in October, 2000, in which many
of the same points were mentioned.)
There will always be a risk that on an unfamiliar system, a word
found might actually differ from the intended one, or a word sought
might be present but not found.
In the great majority of uses of [DEFINED] and [UNDEFINED] they are
followed with [IF]. Thus it might be convenient to have words like
[IFDEF] which incorporate the action of IF. The proposed words could
be factors for these.
Standardization would be convenient.
</pre>
<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).
<pre>
[ ] 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.
</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 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.
<h4>Credits</h4>
Proponent: Charles G Montgomery<br>
Votetaker: M. Anton Ertl
<hr><a href="http://www.complang.tuwien.ac.at/anton/">Anton Ertl</a>