Throw IORs

[ RfDs/CfVs | Other proposals ]
  1. Current Poll Standing
  2. Problem
  3. Current practice
  4. Solution
  5. Proposal
  6. Comments
  7. Voting instructions

Poll standings

See below for voting instructions.

Systems

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

Programmers

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

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   THROW  ENDIF
or
: ?THROW    \ ior throwcode --
  SWAP IF  THROW  ELSE  DROP  THEN  ;

  ALLOCATE  ?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
nameTypeConstant?Meaning
X:ThorwIORs - - the X:ThowIORs extension is present
THROW/ior impact - table 9.2 in Basis1
valuetext
-59ALLOCATE
-60FREE
-61RESIZE
-62CLOSE-FILE
-63CREATE-FILE
-64DELETE-FILE
-65FILE-POSITION
-66FILE-SIZE
-67FILE-STATUS
-68FLUSH-FILE
-69OPEN-FILE
-70READ-FILE
-71READ-LINE
-72RENAME-FILE
-73REPOSITION-FILE
-74RESIZE-FILE
-75WRITE-FILE
-76WRITE-LINE

Comments

Bernd Paysan
The ballot system doesn't work well to describe how Gforth and bigFORTH do it, so I explain it in words:

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.

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 .ERROR 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 WRITE-FILE 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.

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.

Stephen Pelc points out that the proposal does not say that you must 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.

Given the range of hardware and O/S, it is impossible in a standard to go beyond saying that WRITE-FILE failed and a THROW occurred. Most hosted systems require further work to get an extended error code and/or string.

Graham Smith
Yes! And I grow tired of reinventing this sort of thing for each application.

Voting instructions

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.

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.
Proponent: Stephen Pelc
Votetaker: Peter J Knaggs