Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.lang.forth
Subject: QUIT and ABORT (was: Why dial-a-standard is not a thing in Forth)
Date: Sat, 03 May 2025 05:25:17 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 71
Message-ID: <2025May3.072517@mips.complang.tuwien.ac.at>
References: <87bjtn2hct.fsf@gmail.com> <nnd$3b017059$6aa9c908@b5507bbc6e704cf6> <5ce2cb85311aa91fcb7ab57c802aef09b3345163@i2pn2.org> <nnd$1667d791$2eba7243@d7216ffec373a0d9> <nnd$595f502c$48101358@27425914746d2863> <d9149a9d12db559e2720156b315fcfdcdd90e3fe@i2pn2.org>
Injection-Date: Sat, 03 May 2025 08:07:44 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="d230db8aa85e68b3bc438415dc7f1948";
	logging-data="3085049"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+BDgeyxzKV9NWMK5p+elL/"
Cancel-Lock: sha1:D6R34asXcKfciKzfZbPJxNRYV9k=
X-newsreader: xrn 10.11
Bytes: 3907

dxf <dxforth@gmail.com> writes:
>Technically both end an application distinguished only by the fact
>QUIT lets you examine what was on the stack.

If a Forth system implements 9.6.2.0670 ABORT (the version from the
optional Exception extension wordset), the application can CATCH an
ABORT and then continue.  There is no way for the application to catch
QUIT on any standard system.

>For reasons known only to ANS (and maybe
>Mitch Bradley) both were assigned exception codes and thus CATCHable.

It's not clear what is the intention for throw code -56; Table 9.1
just says "QUIT", but there is no redefinition of the word QUIT in a
way similar to 9.6.2.0670 ABORT, so every system has to imlement
6.1.2050 QUIT, which does not THROW.

> A QUIT is considered by the OS as a
>'success' whereas as an uncaught ABORT (or other exception) means
>'failure'.

How does "the OS" (whichever one you mean) come into play with QUIT or
ABORT?  According to Forth-94/2012, both result in the Forth system
continuing to run.  So the Forth system does not exit, and the Unix
notion of an exit code indicates success (0) or failure (anything
else) does not apply (I guess other OSs with shell scripting have
similar notions).

That being said, when you invoke a word in Gforth through the -e
command-line option, if that word produces an uncaught THROW, Gforth
exits with a non-zero exit code (in the development version):

[~/gforth:157361] gforth -e abort
[~/gforth:157362] echo $?
1
[~/gforth:157363] gforth -e "0 @"

*args*:2:3: error: Invalid memory address
0 >>>@<<<
[~/gforth:157364] echo $?
139
[~/gforth:157365] gforth -e "-3 throw"

*args*:2:4: error: Stack overflow
-3 >>>throw<<<
[~/gforth:157366] echo $?
1
[~/gforth:157367] gforth -e "-9 throw"

*args*:2:4: error: Invalid memory address
-9 >>>throw<<<

The "0 @" case is funny: First, gforth translates the SIGSEGV (signal
code 13) into -9 THROW, and when the system CATCHes the -9 (because
the application does not) during argument-evaluation, it translates
the -9 into the exit code that you usually get from SIGSEGV: 139
(128+13).

Concerning the standard, the behaviour of Gforth is non-standard when
you invoke a word through -e, but if you want the standard behaviour,
just invoke the word from the Forth command line.  The behaviour when
invoking the word through -e is more useful when using Forth as a
scripting language.

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