Path: ...!weretis.net!feeder9.news.weretis.net!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: dxf <dxforth@gmail.com>
Newsgroups: comp.lang.forth
Subject: Re: QUIT and ABORT
Date: Sat, 3 May 2025 18:08:23 +1000
Organization: i2pn2 (i2pn.org)
Message-ID: <77cc946b102f8976f25ff6fadadd1858a4ffacdb@i2pn2.org>
References: <87bjtn2hct.fsf@gmail.com>
 <nnd$3b017059$6aa9c908@b5507bbc6e704cf6>
 <5ce2cb85311aa91fcb7ab57c802aef09b3345163@i2pn2.org>
 <nnd$1667d791$2eba7243@d7216ffec373a0d9>
 <nnd$595f502c$48101358@27425914746d2863>
 <d9149a9d12db559e2720156b315fcfdcdd90e3fe@i2pn2.org>
 <2025May3.072517@mips.complang.tuwien.ac.at>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 3 May 2025 08:08:27 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2925410"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="XPw7UV90Iy7EOhY4YuUXhpdoEf5Vz7K+BsxA/Cx8bVc";
User-Agent: Mozilla Thunderbird
In-Reply-To: <2025May3.072517@mips.complang.tuwien.ac.at>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-GB
Bytes: 4755
Lines: 86

On 3/05/2025 3:25 pm, Anton Ertl wrote:
> 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.

Whether they did or not, none of the systems I tried was it possible
to catch QUIT .  But this may simply be as a consequence of following
the sample error handler given in the Rationale which uses QUIT itself.
In this instance QUIT can't catch itself. 
>> 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).

In DX-Forth if the interactive forth environment is active then QUIT
and ABORT do as one would expect.  For turnkeys they exit to the OS
with codes 0 and 1 respectively.  Where other exit codes are desired
there exists RETURN (see below).

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

To what extent Standard Forth considered OS-based turnkeys (with or without
embedded compiler) I had to consider it.  To this end I implemented:

 RETURN  ( x -- )                                      A

     Restore initial drive/path then return to DOS with exit code x
     where x is a value in the range 0 to 255.  Open files are not
     closed.

BYE closes any open compiler-related files, restores console mode and
attributes and then performs 0 RETURN .