forked from Forth-Standard/forth200x
/
ekey-event.html
170 lines (142 loc) · 5.61 KB
/
ekey-event.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
<html>
<head>
<title>EKEY Event Record</title>
<style type="text/css">
ol li { margin-bottom: 2ex; }
</style>
</head>
<body>
<h3>EKEY Event Record</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 (Bernd Paysan)
</dd>
<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>
<dd> SwiftForth (Leon Wagner)
<br/> SwiftX (Leon Wagner)
</dd>
<dt> [ ] There are no plans to implement the proposal in full in [ ].</dt>
<dd> 4tH (Hans Bezemer)
</dd>
<dt> [ ] will never implement the proposal in full.</dt>
<dd> bigForth (Bernd Paysan)
</dd>
</dl>
<h5>Programmers</h5>
<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>
<dd> Leon Wagner
</dd>
<dt> [ ] I would use (parts of) this proposal in my programs if this proposal was in the Forth standard.</dt>
<dd> Bernd Paysan
</dd>
<dt> [ ] I would not use (parts of) this proposal in my programs.</dt>
<dd> Hans Bezemer
</dd>
</dl>
<h4>Informal Results</h4>
<ul>
<li> Anton Ertl<br/>
Since the proposal does not propose an extension, but a restriction
the poll questions should be different than for an extension:
<p>
For systems, it might ask whether it would implement EKEY with this
restriction, but not without it (and maybe, in the informal results,
why), or whether the restriction makes not difference. Or, if the
restriction is adopted in the standard, the system will exploit it.
</ul>
<table width="500"><tr><td>
<h3>Problem</h3>
The rationale for EKEY allows for an "event record" being returned
but the word has a signature of ( -- u ) which forbids the address of
such a record being returned.
<h3>Solution</h3>
Correct the stack signature of EKEY to ( -- x ) in order to allow an
address to be returned. The stack descriptions of both EKEY>CHAR and
EKEY>FKEY must also be changed to allow them to accept an address (x)
rather than a value (u).
<h3>Proposal</h3>
<ol>
<li> Replace u with x in the definition of 10.6.2.1305 EKEY.
<br />( -- u ) becomes ( -- x )</li>
<li> Replace the u with x in the definition of 10.6.2.1306
EKEY>CHAR. <br />( u -- u false | char true ) becomes
( x -- x false | char true ).</li>
<li> Change the definition of 10.6.2.xxxx EKEY>FKEY from<br />
( u1 -- u2 f ) to ( x -- u flag ).</li>
<li>Define the lifetime of the "event record" by adding the following
to the definition of 10.6.2.1305 EKEY:
<blockquote>
x is valid until the next call to EKEY or EKEY?.
</blockquote>
</li>
</ol>
<h4>Change History</h4>
<dl>
<dt>2010-02-24</dt>
<dd>Minor revisions</dd>
<dt>2009-09-03</dt>
<dd>Separated from KEY/EKEY proposal.</dd>
<dt>2009-03-31</dt>
<dd>Original Text</dd>
</dl>
<h3>Author</h3>
Peter Knaggs <pjk@bcs.org.uk><br/>
Engineering, Mathematics and Physical Sciences,<br/>
University of Exeter, Exeter, Devon EX4 7QF, England
</td></tr></table>
<a name="voting"><h4>Voting Instructions</h4></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>
<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>
<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.
<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>
<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.
<h4>Credits</h4>
Proponent: <a href="http://www.rigwit.co.uk/">Peter Knaggs</a><br />
Votetaker: <a href="http://www.rigwit.co.uk/">Peter Knaggs</a>
</body></html>