forked from Forth-Standard/forth200x
/
throw-iors.html
241 lines (202 loc) · 8.86 KB
/
throw-iors.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
<title>Throw IORs proposal</title>
<h1><a name="throw-iors">Throw IORs</a></h1>
[ <a href="rfds.html">RfDs/CfVs</a> | <a href="proposals.html">Other proposals</a> ]
<ol>
<li> <a href="#poll">Current Poll Standing</a>
<li> <a href="#problem">Problem</a>
<li> <a href="#current">Current practice</a>
<li> <a href="#solution">Solution</a>
<li> <a href="#proposal">Proposal</a>
<li> <a href="#comments">Comments</a>
<li> <a href="#voting">Voting instructions</a>
</ol>
<h2><a name="poll">Poll standings</a></h2>
See <a href="#voting">below</a> for voting instructions.
<h3>Systems</h3>
<pre>
[ ] conforms to ANS Forth.
PFE (Guido Draheim)
[ ] 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:
PFE
</pre>
<h3>Programmers</h3>
<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:
Graham Smith
[ ] 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>
<h2><a name="problem">Problem</a></h2>
Error codes returned by some words, e.g. <code>ALLOCATE</code> are not
specified, and an application has no entitlement to use them as
<code>THROW</code> codes. The leads to very clumsy code of the form:
<pre>
ALLOCATE IF <lit> THROW ENDIF
</pre>
or
<pre>
: ?THROW \ ior throwcode --
SWAP IF THROW ELSE DROP THEN ;
ALLOCATE <lit> ?THROW
</pre>
However, we also see many instances of code such as
<pre>
ALLOCATE THROW
</pre>
which leads to silent aborts when a system issues <code>-1 THROW</code>
(as it is currently entitled to) or incorrect error messages.
<h2><a name="current">Current Practice</a></h2>
As far as possible within historical and commercial constraints,
MPE has attempted to make <em>ior</em>s <code>THROW</code>able. The
only downside has been some necessary conversion of operating system
error codes to ANS or application error codes.
<p>
Some years ago, some people objected to making <em>ior</em>s the same
as <code>THROW</code> codes because of the documentation overhead. This
RfD is made to sample opinion again, particularly among Forth system
implementers.
<h2><a name="solution">Solution</a></h2>
All words which return an ior should have one value assigned in the
THROW code table (Table 9.2 in 9.3.5). This table reserves values
-1..-255 for system-defined exceptions. Systems that ignore this
proposal are unaffected if they already avoid these values, and
systems that implement this proposal gain use of these new fixed
<em>ior</em>s.
The only downside is that we have to define some new
<code>THROW</code> codes.
<h2><a name="proposal">Proposal</a></h2>
Extend the <code>THROW</code> code table (Table 9.2 in 9.3.5) so that
there is a separate <code>THROW</code> code for each word that returns
an <em>ior</em>.
<h3>Labelling</h3>
ENVIRONMENT? impact - table 3.5 in Basis1
<blockquote>
<table>
<thead>
<tr><th>name</th><th>Type</th><th>Constant?</th><th>Meaning</th></tr>
</thead>
<tbody>
<tr><td><code>X:ThorwIORs</code></td>
<td align="center">-</td>
<td align="center">-</td>
<td>the <code>X:ThowIORs</code> extension is present</td></tr>
</tbody>
</table>
</blockquote>
THROW/ior impact - table 9.2 in Basis1
<blockquote>
<table>
<thead><tr><th>value</th><th>text</th></tr></thead>
<tbody>
<tr><td>-59</td><td><code>ALLOCATE</code></td></tr>
<tr><td>-60</td><td><code>FREE</code></td></tr>
<tr><td>-61</td><td><code>RESIZE</code></td></tr>
<tr><td>-62</td><td><code>CLOSE-FILE</code></td></tr>
<tr><td>-63</td><td><code>CREATE-FILE</code></td></tr>
<tr><td>-64</td><td><code>DELETE-FILE</code></td></tr>
<tr><td>-65</td><td><code>FILE-POSITION</code></td></tr>
<tr><td>-66</td><td><code>FILE-SIZE</code></td></tr>
<tr><td>-67</td><td><code>FILE-STATUS</code></td></tr>
<tr><td>-68</td><td><code>FLUSH-FILE</code></td></tr>
<tr><td>-69</td><td><code>OPEN-FILE</code></td></tr>
<tr><td>-70</td><td><code>READ-FILE</code></td></tr>
<tr><td>-71</td><td><code>READ-LINE</code></td></tr>
<tr><td>-72</td><td><code>RENAME-FILE</code></td></tr>
<tr><td>-73</td><td><code>REPOSITION-FILE</code></td></tr>
<tr><td>-74</td><td><code>RESIZE-FILE</code></td></tr>
<tr><td>-75</td><td><code>WRITE-FILE</code></td></tr>
<tr><td>-76</td><td><code>WRITE-LINE</code></td></tr>
</tbody>
</table>
</blockquote>
<h2><a name="comments">Comments</a></h2>
<dl>
<dt> <b>Bernd Paysan</b>
<dd>
The ballot system doesn't work well to describe how Gforth and bigFORTH do
it, so I explain it in words:
<p>
Gforth and bigFORTH have made IORs throwable since the dawn of their ANS
Forth compatibility (both during the draft process). However, we use the
system-specific part of the throw code table, and have a way how to convert
signal and errno numbers into the THROW space.
<p>
If you relax your proposal in such a way that IORs must be throwable, and
the system also must provide a way to print out diagnostic strings (e.g.
the <code>.ERROR</code> we have in Gforth), a consent is easier to reach.
I like to keep as much information as possible about the original error,
so mapping errors to words that misbehave isn't such a good idea - a word
like <code>WRITE-FILE</code> can fail for quite a number of reasons (no
space left on device, pipe closed, low-level IO error, buffer outside address
space, etc.). A backtracing utility is a better way to locate the error, and
you'll then see which word misbehaved, as well.
<p>
So in general, I fully support the part of your proposal where IORs are made
throwable, but I don't support your throw code scheme.
<p>
<b>Stephen Pelc</b> points out that the proposal does not say that you <b>must</b>
use these throw numbers, it says that if you use these numbers, this is what
the standard means by those specific numbers. Consequently gForth will not
conflict with the proposal.
<p>
Given the range of hardware and O/S, it is impossible in a standard to go
beyond saying that <code>WRITE-FILE</code> failed and a <code>THROW</code>
occurred. Most hosted systems require further work to get an extended error
code and/or string.
<dt> <b>Graham Smith</b>
<dd>
Yes! And I grow tired of reinventing this sort of thing for each application.
</dl>
<h2><a name="voting">Voting instructions</a></h2>
Fill out the appropriate ballot(s) below and mail it/them to me
<pknaggs@bournemouth.ac.uk>. 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.
<h3>Ballot for systems</h3>
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.
<h3>Ballot for programmers</h3>
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.
<hr>
Proponent: <a href="http://www.mpeforth.com/">Stephen Pelc</a><br>
Votetaker: <a href="http://dec.bournemouth.ac.uk/staff/pknaggs">Peter J Knaggs</a>