Re: QUIT and ABORT

On 4/05/2025 11:33 pm, Anton Ertl wrote:

dxf <dxforth@gmail.com> writes:

On 4/05/2025 2:02 am, Anton Ertl wrote:

dxf <dxforth@gmail.com> writes:

Checking the doc it says:
>
 9.3.5 Possible actions on an ambiguous condition
>
 A system choosing to execute THROW when detecting one of the ambiguous
 conditions listed in table 9.3.6 shall use the throw code listed there.

>
Calling ABORT or QUIT is not an ambiguous condition, so that section
plays no role there.

>
Yet ABORT ABORT" and QUIT are present in the table and assigned codes.

 
For ABORT the section 9.6.2.0670 specifies that it performs a -1
THROW.  While -1 happens to be the value shown in table 9.1 as being
reserved for ABORT, there is no ambiguous condition involved here.
Likewise for -2, ABORT" and section 9.6.2.0680.

If and only if EXCEPTION EXT is implemented are those mandatory.  Otherwise
they are optionally CATCHable at the implementer's discretion per section
9.3.5 above.

So table 9.1 is useful beyond the purpose of assigning throw codes to
ambiguous conditions.  However, for QUIT there is no redefinition in
chapter 9.

Again only because ANS hadn't specified QUIT as mandatory.  For all I know
it was because it would have killed the QUIT-based exception handler ANS
offered.  To not include QUIT in Table 9.2 would have raised questions as
to why not.

It is clear to me all three are candidates for CATCHing and that this
was the intent.

 
It may have been the intent of adding the -56 throw code to also have
a corresponding redefinition of QUIT in Chapter 9, but they did not
follow through on it.  Maybe because -56 THROW changes the data stack
depth while QUIT does not.

That's a bundle of maybe's.  I believe I've given an explanation that
requires no suppositions.

This is confirmed by the EXCEPTION EXT wordset in which
ABORT and ABORT" are required to be CATCHable irrespective of their
category.

 
Category?

ABORT ABORT" QUIT not being exceptions
 

A system that implements 9.6.2.0670 makes ABORT catchable, and a
system that implements 9.6.2.0680 makes ABORT" catchable.  I find it
perverse that these words are in Exception ext, so you could have a
system that has CATCH, but an uncatchable ABORT and/or an uncatchable
ABORT".  And for QUIT, the standard as it is does not have a catchable
variant at all.

In fact all of the conditions listed in Table 9.2 are optional.  Only
CATCH and THROW are mandatory.  I read that to mean a standard program
can only rely on positive codes it has specified itself.
 

 : QUIT -56 THROW ;

>
That would not be a standard system, because in a standard system QUIT
must do what 6.1.2050 QUIT says, and "-56 THROW" is not a correct
implementation of that.

>
No for the fact QUIT is CATCHable by virtue of its inclusion in the table
of codes in Section 9.

 
There is nothing in the standard that makes such a connection (unlike
for ABORT and ABORT").  I don't know for what purpose -56 was added to
the table, > but I know (and we have the proposal text) for what purpose
-59 (ALLOCATE) was added to the table, and it was not with the intent
of redefining ALLOCATE as
 
: ALLOCATE -59 THROW ;
 
So obviously it's just your interpretation of the table that if the
description of a throw code C contains a word name W, systems
implementing the exception wordset are free to redefine W as throwing
C.

Again it's an interpretation that fits what is present in ANS.

...