Re: QUIT and ABORT

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.

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.

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.

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

Category?

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.

 : 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.

If OTOH you believe the inclusion of ABORT ABORT"
and QUIT was made in error then you have the option of testing that by
making a proposal to have them removed.

The throw codes -1 and -2 were obviously added due to 9.6.2.0670 and
9.6.2.0680, not at all in error.  I do not know why -56 was added, but
it does not hurt, and existing programs might use it, so there is no
good reason to remove it from the table.

Admittedly, the presence in the table results in no guarantees from
the standard, so removing the entry for -56 would not really hurt,
either.  In any case, such a proposal would only poll the opinion of
the current committee, so it's not a way to find out whether the
Forth-94 committee consider the addition of -56 to the table as a
mistake.

If someone made a proposal to the committee, existing practice would
probably be considered more important than whatever we can still
determine about the intent of the Forth-94 committee.  I don't know a
way to determine how many programs there are around that expect QUIT
to be catchable, or that expect it not to be catchable, but for
systems we can check relatively easily what they do:

Here's the code I give to the Forth systems:

1 .( a ) cr -56 throw .( b )
.s
2 .( a ) cr quit .( b )
.s
: foo 3 -56 throw ; ' foo catch 5
.s
: bar 4 quit ; ' bar catch 6
.s

Let's see what different Forth systems do:

Gforth 0.7.9_20250409
1 .( a ) cr -56 throw .( b ) a

*the terminal*:1:17: error: QUIT
1 .( a ) cr -56 >>>throw<<< .( b )
.s <0>  ok
2 .( a ) cr quit .( b ) a

.s <1> 2  ok 1
: foo 3 -56 throw ; ' foo catch 5  ok 3
.s <3> 2 -56 5  ok 3
: bar 4 quit ; ' bar catch 6
.s <4> 2 -56 5 4  ok 4


iForth 5.1-mini
FORTH> 1 .( a ) cr -56 throw .( b ) a

FORTH> .s
  Data: ---
System: ---
 Float: --- ok
FORTH> 2 .( a ) cr quit .( b ) a

[1]FORTH> .s
  Data: 2 ---
System: ---
 Float: --- ok
[1]FORTH> : foo 3 -56 throw ; ' foo catch 5
[1]FORTH> .s
  Data: 2 ---
System: ---
 Float: --- ok
[1]FORTH> : bar 4 quit ; ' bar catch 6
[2]FORTH> .s
  Data: 2 4 ---
System: ---
 Float: --- ok

SwiftForth x64-Linux 4.0.0-RC89 15-Jul-2024
1 .( a ) cr -56 throw .( b ) a
QUIT
.s
<-Top  ok
2 .( a ) cr quit .( b ) a
.s
2 <-Top  ok
: foo 3 -56 throw ; ' foo catch 5  ok
.s
2 -56 5 <-Top  ok
: bar 4 quit ; ' bar catch 6 .s
2 -56 5 4 <-Top  ok

VFX Forth 64 5.43 [build 0199] 2023-11-09 for Linux x64

1 .( a ) cr -56 throw .( b ) a

No text available for THROW code -56(10)
 -> 1 .( a ) cr -56 throw .( b )
                         ^
.s
DATA STACK
empty stack
 ok
2 .( a ) cr quit .( b ) a

.s
DATA STACK
     top
              2 0000:0000:0000:0002
 ok-1
: foo 3 -56 throw ; ' foo catch 5  ok-3
.s
DATA STACK
     top
              5 0000:0000:0000:0005
            -56 FFFF:FFFF:FFFF:FFC8
              2 0000:0000:0000:0002
 ok-3
: bar 4 quit ; ' bar catch 6
.s
DATA STACK
     top
              4 0000:0000:0000:0004
              5 0000:0000:0000:0005
            -56 FFFF:FFFF:FFFF:FFC8
              2 0000:0000:0000:0002

So Gforth, SwiftForth, and VFX behave the same way: QUIT is not
catchable, while -56 THROW is; QUIT does not produce output, while an
uncaught -56 THROW results in output from the system.

In iForth 5.1-mini QUIT preserves the stack while an uncaught -56
THROW resets it to empty (as it should); the uncaught -56 THROW does
not produce a message.  For the cases with CATCH, the FOO variant does
not put the -56 on the stack and does not text-interpret the 5
afterwards, but it does preserve the 2 that was pushed earlier.
Strange.  The BAR variant behaves as expected.  If I try

2 : foo 3 1 throw ; ' foo catch 5
.s

iForth 5.1-mini behaves as follows:

FORTH> 2 : foo 3 1 throw ; ' foo catch 5  ok
[3]FORTH> .s
  Data: 2 1 5 ---
System: ---
 Float: --- ok

This is expected, so it seems to do something special for -56 THROW.

- 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/