From: dxforth@gmail.com
On 3/05/2025 3:25 pm, Anton Ertl wrote:
> dxf 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 .
--- SoupGate-DOS v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
