forked from Forth-Standard/forth200x
/
synonym.html
231 lines (196 loc) · 7.23 KB
/
synonym.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
<title>Synonyms proposal</title>
<h3>Synonym</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>
<dl>
<dt> [ ] conforms to ANS Forth.</dt>
<dd> bigForth<br/>
VFX Forth<br/>
MPE Forth Cross Compilers<br/>
iForth<br/>
SwiftForth<br/>
SwiftX Cross Compilers<br/>
Win32Forth
</dd>
<dt> [ ] already implements the proposal in full since release [ ]:</dt>
<dd> VFX Forth (since 1998)<br/>
MPE Forth Cross Compiers (since 1999)<br/>
Win32Forth (since releae 1)
</dd>
<dt> [ ] implements the proposal in full in a development version:</dt>
<dd> bigForth</dd>
<dt> [ ] will implement the proposal in full in release [ ].</dt>
<dd> bigForth 2.4.0<br/>
4tH 3.60.1</dd>
<dt> [ ] will implement the proposal in full in some future release.</dt>
<dd> iForth<br/>
SwitfForth<br/>
SwitfX Cross Compilers
</dd>
<dt> [ ] There are no plans to implement the proposal in full in [ ].</dt>
<dt> [ ] will never implement the proposal in full:</dt>
</dl>
<h5>Programmers</h5>
<dl>
<dt> [ ] I have used (parts of) this proposal in my programs:</dt>
<dd> Graham Smith<br/>
Bernd Paysan<br/>
Stephen Pelc<br/>
Marcel Hendrix<br/>
George Hubert<br/>
Michael D. Morris
</dd>
<dt> [ ] I would use (parts of) this proposal in my programs if the systems
I am interested in implemented it:</dt>
<dd> Josh Grams<br/>
Leon Wagner<br/>
Michael D. Morris<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> Josh Grams<br/>
Leon Wagner<br/>
Michael D. Morris<br/>
Gerry Jackson
</dd>
<dt> [ ] I would not use (parts of) this proposal in my programs.</dt>
<dd> Hans Bezemer<br/>
Bruce R. McFarling
</dd>
</dl>
<h5>Informal results</h5>
Maybe some extra ambiguous conditions must be defined.
I won't implement this proposal until it has gotten some
serious thought.
<h4>Problem</h4>
Various words have been used to generate a new name for an
existing word. This required when porting code and when
generating application wordlists that contain a reference
to an existing word, e.g. when providing limited access
to Forth system kernel words.
<p>
Especially with native code compiling Forth systems and cross
compilers, these words have not provided full access to the
required behaviour. The behaviour may require carnal knowledge
of the underlying system, which is one reason why SYNONYM should
be standardised.
<h4>Current practice</h4>
The proposed form <code>SYNONYM</code> has been in use at MPE
with cross compilers and VFX Forth since 1998. It is also
implemented in Win32Forth and PFE.
<p>
Many people have suggested that we stay with words such as
<code>AKA</code>, <code>ALIAS</code> or <code>ALIAS:</code>,
usually of the form
<pre>
' oldname ALIAS newname
</pre>
This has merit in terms of common practice, but will break
code for several systems. Some systems, e.g. cross compilers,
cannot generate enough information using the <em>xt</em> of a
word alone. All surveyed systems can implement
<code>SYNONYM</code>.
<h4>Solution</h4>
Although many people have objected to parsing words, parsing
permits the host system the most flexibility in implementation
and is thus the preferred solution.
The syntax is:
<pre>
SYNONYM <newname> <oldname>
</pre>
where <newname> will behave identically to <oldname>.
Note that <newname> may be the same as <oldname>.
<h4>Proposal</h4>
<pre>
10.6.2.xxxx SYNONYM FACILITY EXT
X:synonym
</pre>
<dl>
<dd> ( "<spaces>newname" "<spaces>oldname" -- )<br>
For both strings skip leading space delimiters. Parse name
delimited by a space. definition for newname with the semantics
defined below. Newname may be the same as oldname.
<p>
<dt> <em>newname</em> interpretation: ( i*x -- j*x )
<dd> Perform the interpretation semantics of <em>oldname</em>
<p>
<dt> <em>newname</em> compilation: ( i*x -- j*x )
<dd> Perform the compilation semantics of <em>oldname</em>
<p>
<dt>Ambiguous conditions:
<dd> <em>oldname</em> is not found.
<dd> <code>IMMEDIATE</code> is used for a word defined by
<code>SYNONYM</code>.
</dl>
<h4>Reference Implementation</h4>
The implementation of <code>SYNONYM</code> requires carnal
knowledge of the host implementation, which is one reason why
it should be standardised.
The implementation below is imperfect and specific to VFX Forth.
<pre>
: Synonym \ <"new-name"> <"curdef"> --
\ *G Create a new definition which redirects to an existing one.
create immediate
hide ' , reveal
does>
@ state @ 0= over immediate? or
if execute else compile, then
;
</pre>
<h4>Change history</h4>
<dl>
<dt>2008-09-26</dt>
<dd>Updated ambiguous conditions.</dd>
<dt>2006-09-22</dt>
<dd>Enhanced current practice section.<br/>
Fixed some typos.</dd>
<dt>2006-08-21</dt>
<dd>First draft.</dd>
</dl>
<h4><a name="voting">Voting instructions</a></h4>
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.
<h5>Ballot for systems</h5>
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> [ ] already implements the proposal in full since release [ ].
<dt> [ ] implements the proposal in full in a development version.
<dt> [ ] will implement the proposal in full in release [ ].
<dt> [ ] will implement the proposal in full in some future release.
<dt> [ ] There are no plans to implement the proposal in full in [ ].
<dt> [ ] will never implement the proposal in full.
</dl>
If you want to provide information on partial implementation, please
do so informally, and I will aggregate this information in some way.
<h5>Ballot for programmers</h5>
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> [ ] I would use (parts of) this proposal in my programs if the systems
I am interested in implemented it.
<dt> [ ] I would use (parts of) this proposal in my programs if this
proposal was in the Forth standard.
<dt> [ ] I would not use (parts of) this proposal in my programs.
</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.
<h4>Credits</h4>
Proponent: <a href="http://www.mpeforth.com/">Stephen Pelc</a><br>
Votetaker: <a href="http://www.rigwit.co.uk/">Peter J Knaggs</a>