RfD - THROW codes and Iors

[Stephen Pelc]

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

[Bernd Paysan]

Post by Stephen Pelc
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.

We do that, too (both in Gforth and bigFORTH), and use a separate IOR space
for OS errors. We don't convert IORs into ANS or application error codes,
but we provide a way to print IORs in a meaningful way (.error takes a
throw code or an IOR, and prints an error message, using strsignal and
strerror from libc to convert IORs into strings - or the related Windows
function, which I can't recall at the moment).

Error space is from -256 to -511 for signals, and from -512 to -2047 for
system errors (IORs). We do convert signal codes that have a meaning in ANS
Forth to ANS Forth codes, like interruption (^C).

Post by Stephen Pelc
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.

That doesn't seem such a clever idea for me. If OPEN-FILE fails, I'd rather
want to know why it failed ("permission denied", "illegal character in file
name", or "out of file handles" or whatever the problem is) than that it
was OPEN-FILE which failed. I probably get that information out of the
backtrace anyway.

[Albert van der Horst]

Post by Stephen Pelc
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.
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.

I'm so strongly in favor of throwable io-codes that I sacrificed
ISO-compatibility in this respect in ciforth.

Post by Stephen Pelc
--

Groetjes Albert

--

[Anton Ertl]

Post by Albert van der Horst
I'm so strongly in favor of throwable io-codes that I sacrificed
ISO-compatibility in this respect in ciforth.

I don't see a conflict between throwable IORs and a system's standard
compliance. What did you do, and why?

Fup2 clf.

- anton

[werty]

Modern s/w has kernel doin all ALLOCATE ,
NewForth allows DICTIONARY ONLY !
You can only put stuff in D' !! No need to figure it .
typically low level coding uses a form of ALLOCATE , but the next
time you need it , you use parts of your code to make this
transparent , so you can concentrate on import stuff .
As you code , you answer questions from kernel
and it then knows how to warn you about asking too much
RAM . This is NOT a 16KB Forth on a Z-80 nor ANSI Forth !!!!
----------------------

Now tell me why i cant link ABSOLUTELY everything !
a serial number for every Dict entry !!
LFA is only 8 bits in Primatives , 16 bits in midlevel and higher
and yet it is UNLIMITED , it can link gigabytes of dict !
There is one dict , but look close and you can see
Vocabs embeded ! No speed penalty ...

How de do dat ?

Post by Stephen Pelc
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.
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
--
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: [phone], fax: [phone]
web: http://www.mpeforth.com - free VFX Forth downloads