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/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <2025May3.072517@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
<SNIP>

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.

I don't think this -e behaviour is needed in an interpreted Forth.
You get the message right away anyhow.
For turnkey and scripts this behaviour is in fact the more useful.
ciforth does behave like this automatically.

~/PROJECT/ciforths/ciforth/TOOLS: cat gobeserk.frt
: doit 19 THROW ;
~/PROJECT/ciforths/ciforth/TOOLS: lina -c gobeserk.frt ~/PROJECT/ciforths/ciforth/TOOLS: gobeserk
? ciforth ERROR # 19 : CONDITIONALS NOT PAIRED

~/PROJECT/ciforths/ciforth/TOOLS: echo $?
19

So I saved the -e option meaning "load the electives screen".

- anton

Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)