Re: THROW codes and ambiguous conditions

dxf <dxforth@gmail.com> writes:

AFAICS the statement in Section 9.3.5
>
"A system choosing to execute THROW when detecting one of the ambiguous
 conditions listed in table 9.2 shall use the throw code listed there."
>
effectively rules out the traditional use of ABORT" to convey the ambiguous
conditions listed in the table.  Is that how others read it?

Given that the standard states elsewhere that there is no guarantee of
any system behaviour at all in case of an ambiguous condition, this
statement and its use of "shall" is strange.

Let's see what the existing practice is.  I try the following on
various Forth systems:

s" include xxxxxxxx.fs" ' evaluate catch .
s" include /tmp/x.fs"   ' evaluate catch .

where xxxxxxxx.fs does not exist, and /tmp/x.fs exists but the
permissions are such that you cannot open it for reading.

What I get on various Forth systems running on Linux is:

xxxxxxxx.fs /tmp/x.fs
  -514        -525    Gforth
   -37         -37    iforth 5.1-mini
  -261        -261    lxf 1.7-172-983
  -199        -199    SwiftForth i386-Linux 3.11.0
   -69         -69    SwiftForth x64-Linux 4.0.0-RC89
  -258        -258    VFX Forth 64 5.43

So out of these five systems, only two use values from the table, and
these two use different throw codes.  Only one uses a throw code from
the original 50 that Mitch Bradley had in mind when creating the
table.

Looking at 11.6.1.1718 INCLUDED, it says:

|An ambiguous condition exists if the named file can not be opened, if
|an I/O exception occurs reading the file, or if an I/O exception
|occurs while closing the file.

Table 9.1 of Forth-2012 lists:

-37 file I/O exception
-38 non-existent file
-69 OPEN-FILE

Looking at 11.4.1.2 of Forth-94
<https://www.complang.tuwien.ac.at/forth/dpans-html/dpans11.htm>, it
lists the following ambiguous conditions for INCLUDED:

* I/O exception reading or closing fileid (11.6.1.1717 INCLUDE-FILE,
  11.6.1.1718 INCLUDED);
* named file cannot be opened (11.6.1.1718 INCLUDED);

It's unclear how these ambiguous conditions should be mapped to the
throw codes.

In any case, -38 is the best match for the xxxxxxxx.fs case, and among
the first 50, -37 is the best match for the /tmp/x.fs case; with the
addition of -69 in Forth-2012, -69 is also a contender; however, the
throw codes -59..-76 were intended for explicit throws of iors, not
for ambiguous conditions (neither the proponent of that addition nor
the committee ever discussed the chapter where the table is defined).

Since it's inception, Gforth has thrown other throw codes in all cases
where the OS reported a failure (as is the case here: -514 means "No
such file or directory" and -525 means "Permission denied") and in
some cases when the OS raised a signal, and nobody has complained
about that yet; the fact that several other Forth systems do not use
throw codes from Table 9.1 for these ambiguous conditions indicates
that their authors have not received complaints about that, either.

But maybe Forth, Inc. received such a complaint, and that's why they
changed the throw code from -199 to -69.  Or maybe not: The fact that
they changed the throw code indicates that they do not worry that
their customers have programs written for their old throw codes; note
also that if the system catches a -199 THROW on SwiftForth 3.11, it
reports "Can't open file", just like SwiftForth 4.0.0-RC89 does when
it catches a -69 THROW.  Doing the other throw on either version
produces the following messages: "Catch = -69" and "Catch = -199".

My guess is that those programmers who catch such ambiguous conditions
do not check the actual throw codes, at least not if they write
programs intended to be portable across systems (some may be writing
system-specific programs and check for the specific throw codes these
systems produce; but the renumbering in SwiftForth indicates that
Forth, Inc. does not expect that their users do that even in a
system-specific way).

So I would not worry about that.

Early on DX-Forth it became apparent that maintaining a list of error
messages accessible by means of a THROW code was going to be messy and
worse - costly.  I wanted CATCH THROW but could do without the vision
ANS appeared to have in mind for it.  The consequence of retaining
ABORT" for classic ambiguous conditions means I can't individually
identify them at CATCH but I've yet to find this a problem.

It probably is not a problem, but your claim of a high cost seems
curious.  It seems to me that

open-file throw

is cheaper than

open-file abort" OPEN-FILE failed in INCLUDED"

and that reporting something like "Catch = -37" or somesuch is not
costly to implement at all.  And if you want more descriptive error
messages in a resource-constrained and otherwise traditional setting,
using the throw code to select a line from a sequence of blocks does
not seem to be particularly expensive, either.

I'm curious whether others found ANS' requirement above 'a step too far'?

It seems that if we have noticed it at all, many of us chose to ignore
it.

However, in the case of signals Gforth goes to quite some lengths to
actually translate it to the right Forth exception, and while we are
at it, also produce a throw code from table 9.1.

E.g., when it receives a SIGFPE, it looks at the si_code of the
signal, and if that is FPE_INTDIV (integer division error), the
debugging engine (gforth) checks if the divisor is 0.  If so, it
throws -10 (division by zero), otherwise (e.g., on $8000000000000000
-1 / ) it throws -11 (Result out of range).

Another example is SIGSEGV.  It looks up the accessed memory address
(si_addr), and depending on where that points to, throws one of:

   -3 Stack overflow
   -4 Stack underflow
   -5 Return stack overflow
   -6 Return stack underflow
   -8 Dictionary overflow
   -9 Invalid memory address
  -44 Floating-point stack overflow
  -45 Floating-point stack underflow
-2058 locals stack overflow
-2059 locals stack underflow

I don't think that the resulting throw codes are checked in any
programs, but I expect that the users find the error messages (when
the system catches the exception) helpful; I certainly do.

- 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: https://forth-standard.org/
EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/