RfD - THROW codes and Iors
Stephen Pelc
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, steph...@mpeforth.com
MicroProcessor 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
Bernd Paysan
> 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).
> 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.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Albert van der Horst
Stephen Pelc <steph...@INVALID.mpeforth.com> wrote:
>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.
I'm so strongly in favor of throwable io-codes that I sacrificed
ISO-compatibility in this respect in ciforth.
>--
>Stephen Pelc, steph...@mpeforth.com
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
alb...@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst
Anton Ertl
>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
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2006: http://www.complang.tuwien.ac.at/anton/euroforth2006/
Anton Ertl
>> 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.
Seconded. Also, defining these values and changing the
implementations to conform with this would require a lot of work, with
little gain that I can see.
I would suggest standardizing existing common practice without
overspecifying things that need not be specified. Maybe something
like this:
|Extend 11.3.1.2 along these lines: I/O results are values in the range
|-4095...-1. THROWing them results in an appropriate error message if
|there is no exception frame on the exception stack.
BTW, I just noticed that 9.3.1 says:
|If the File-Access or Memory-Allocation word sets are implemented, it
|is recommended that the non-zero values of ior lie within the range of
|system THROW values, as defined above.
What does not defining explicit ior values lose us? We cannot CATCH
specific errors in a portable program.
However, we actually cannot do that now with the standard values,
either, since the standard does not define when such a THROW of a
standard value happens (unless the user THROWs these values
explicitly); after all, the errors that they cover do not happen in
standard programs (they correspond to ambiguous conditions), and for
non-standard programs there is no guarantee how they behave; the
ambiguous condition could be ignored by the system, or lead to the
appropriate THROW, or to something else completely.
In addition, I have never missed this option. When I use CATCH, I
want to CATCH everything, not just specific errors.
Also, if we defined them, I would give the exceptions names rather
than cryptic numbers (but I guess that would be a hard sell in our
name-stingy community.
Stephen Pelc
(Anton Ertl) wrote:
>Bernd Paysan <bernd....@gmx.de> writes:
>>> 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.
>
>Seconded. Also, defining these values and changing the
>implementations to conform with this would require a lot of work, with
>little gain that I can see.
The proposal explicitly states that you do not have to change your
existing implementation! What it does do is suggest that we reserve
specific THROWcodes for implementers who want them.
Stephen
ward mcfarland
> I don't see a conflict between throwable IORs and a system's standard
> compliance. What did you do, and why?
IORs from the operating system can collide with ANS reserved throw
codes. Mac OS calls return negative numbers from -1 to at least -30788.
Since those IOR's can be used to get a message string from the OS,
remapping them is not a clean solution.
-- w
Anton Ertl
>On Thu, 24 Aug 2006 21:45:48 GMT, an...@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>Bernd Paysan <bernd....@gmx.de> writes:
>>>> 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.
>The proposal explicitly states that you do not have to change your
>existing implementation! What it does do is suggest that we reserve
>specific THROWcodes for implementers who want them.
Still, I see little gain from that. What would a standard program do
with these THROW codes? With your intention, it cannot rely on them
coming out of iors; it might THROW them itself, and let the system
catch it to produce an error message, but that seems pretty pointless
to me; for that kind of thing an extension like
<http://www.complang.tuwien.ac.at/forth/ansforth/exception.html>
would be better.
It's not a big issue; if you see a point in it and want to do the
work, go ahead.
Anton Ertl
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>
>> I don't see a conflict between throwable IORs and a system's standard
>> compliance. What did you do, and why?
>
>IORs from the operating system can collide with ANS reserved throw
>codes. Mac OS calls return negative numbers from -1 to at least -30788.
>Since those IOR's can be used to get a message string from the OS,
Not in a standard program.
>remapping them is not a clean solution.
Apparently you have words for turning IORs into a message string. How
about undoing the remapping in these words?
E.g., in Gforth iors are remapped and can be thrown. We have a word
.error that prints the error message from an exception number or ior.
Internally it unmaps the remapping and then calls strsignal or
strerror (both of which expect error numbers in the range 1..n), or it
just prints one of the Forth-94-defined error messages.
Of course remapping your large range of errors into the range
-4095...-256 (for system-defined THROW codes) is probably non-trivial
and might even be impossible (at least when a reversible mapping is
desired). But if you can't solve this problem, do you expect the
application programmer or user to do it then? What do you expect the
programmer to do with the iors?
If the range provided by ANS Forth is too small, the least range will
be done if you remap the error numbers into some negative range below
-32768, e.g., -100001 to -130788; truely standard programs cannot use
that range anyway, and other programs probably have not used it for
throw codes, either.
Stephen Pelc
(Anton Ertl) wrote:
><http://www.complang.tuwien.ac.at/forth/ansforth/exception.html>
>
>would be better.
>
>It's not a big issue; if you see a point in it and want to do the
>work, go ahead.
VFX already includes an ERRDEF mechanism which generates a constant
associated with an internationalisable message.
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 ?