ThrowIors.txt
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 constarints,
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 stack conditions
THROW/ior impact - table 9.2 in Basis1
value text
--
Stephen Pelc, stephenXXX@[EMAIL PROTECTED]
Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com
- free VFX Forth downloads
|
