This is actually a poll about how widely the proposal is implemented and
how popular it is among the programmers. It is called a CfV
(call-for-votes) because the process is inspired by the Usenet Rdf/CfV
process.

You find the actual ballot further down (look for "VOTING PROCEDURE"),
after the proposal on which you vote.

PROPOSAL

RfD: Throw IORs
Stephen Pelc, 21 August 2006

Rationale
=========

Problem
-------
Error codes returned by some words, e.g. ALLOCATE are not specified,
and an application has no entitlement to use them as THROW codes.
The leads to very clumsy code of the form:

ALLOCATE IF <lit> THROW ENDIF

or

: ?THROW \ ior throwcode --
SWAP IF THROW ELSE DROP THEN ;

ALLOCATE <lit> ?THROW

However, we also see many instances of code such as

ALLOCATE THROW

which leads to silent aborts when a system issues -1 THROW (as
it is currently entitled to) or incorrect error messages.

Current practice
----------------
As far as possible within historical and commercial constraints,
MPE has attempted to make iors THROWable. The only downside has
been some necessary conversion of operating system error codes
to ANS or application error codes.

Some years ago, some people objected to making iors the same as
THROW codes because of the documentation overhead. This RfD is
made to sample opinion again, particularly among Forth system
implementers.

Solution
--------
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
iors.

The only downside is that we have to define some new THROW codes.

Proposal
========
Extend the THROW code table (Table 9.2 in 9.3.5) so that there is
a separate THROW code for each word that returns an ior.

Labelling
=========
ENVIRONMENT? impact - table 3.5 in Basis1
name Type Constant? Meaning
X:ThorwIORs - - the X:ThowIORs extension is present

THROW/ior impact - table 9.2 in Basis1
value text
-59 ALLOCATE
-60 FREE
-61 RESIZE

-62 CLOSE-FILE
-63 CREATE-FILE
-64 DELETE-FILE
-65 FILE-POSITION
-66 FILE-SIZE
-67 FILE-STATUS
-68 FLUSH-FILE
-69 OPEN-FILE
-70 READ-FILE
-71 READ-LINE
-72 RENAME-FILE
-73 REPOSITION-FILE
-74 RESIZE-FILE
-75 WRITE-FILE
-76 WRITE-LINE


VOTING INSTRUCTIONS

Fill out the appropriate ballot(s) below and mail it/them to me
<pknaggs@...>. Your vote will be published (including
your name (without email address) and/or the name of your system) on
<http://www.forth200x.org/thow-iors.html>. You can vote (or change
your vote) at any time by mailing to me, and the results will be
published there.

Note that you can be both a system implementor and a programmer, so
you can submit both kinds of ballots.


Ballot for systems

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).

[ ] 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.

If you want to provide information on partial implementation, please do
so informally, and I will aggregate this information in some way.


Ballot for programmers

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.

[ ] 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.

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.

CREDITS

Proponent: Stephen Pelc
Votetaker: Peter J Knaggs