Can CATCH be applied to ABORT, ABORT", QUIT?

[SirWumpus]

The Forth 200x Draft 19.1 makes no mention as to whether 9.6.2.0670 ABORT, 9.6.2.0680 ABORT", and/or 6.1.2050 QUIT (assuming it ever THROWs) can be CATCH-ed. The stack behaviour of these words would imply that they cannot be caught because the data and/or return stacks are emptied, throwing away any possible exception state saved by CATCH.

Depending on how "Empty the return stack..." and CATCH are implemented, eg. simply changing (and saving) a data/return stack pointers, a THROW might be a simple restoration of stack pointers assuming the stack memory has not been altered.

Can CATCH be applied to ABORT, ABORT", QUIT?

[ruv]

Can CATCH be applied to ABORT, ABORT", QUIT?

CATCH may be applied to any execution token (xt), as well as EXECUTE.

And even if the execution semantics of a Forth definition are specified in such a way that it never returns control to a caller and never throws an exception, this fact should not formally prevent CATCH to be applied to the corresponding execution token. It just never returns control in such a case.

A standard program can obtain the execution tokens for ABORT (EXCEPTION EXT) and QUIT as they are ordinary words. So CATCH can be applied to these words (theirs execution tokens).

A standard program cannot obtain the execution tokens for ABORT" (EXCEPTION EXT) since it's not an ordinary word, since interpretation semantics for it are not defined by the standard. So CATCH cannot be applied to ABORT". But it can be applied to a Forth definition that uses ABORT", for example :noname true abort" test passed" ; catch

The stack behaviour of these words would imply that they cannot be caught because the data and/or return stacks are emptied, throwing away any possible exception state saved by CATCH.

It's not quite correct.

CORE ABORT and CORE ABORT" are updated in the Exception word set so they perform the function of -1 THROW and -2 THROW correspondingly.

In its turn, THROW can perform the function of CORE ABORT or the run-time semantics of CORE ABORT" (and empty the data and return stack) only if there is no an exception frame on the exception stack.

But if an exception frame exists, then THROW doesn't empty but restores depth of stacks, and transfers control to a point just after the CATCH that pushed the topmost exception frame.

Actually, the behavior of THROW is specified unclear in this regard, you need to read it very carefully to understand these nuances. There is a proposal to make this specification more clear.

---

An interesting question is whether CATCH can ever return control to the caller when it is applied to QUIT.

QUIT doesn't empty the exception stack, so if THROW is performed during interpretation, and an exception frame exists, then control should be passed after the corresponding CATCH. But in the reference implementation for QUIT (NB: reference implementations are not normative) it applies CATCH to INTERPRET and doesn't rethrow an exception, if any. So the external CATCH (by which QUIT is called) will be ignored — i.e., the system behaves as there is no any exception frame, and it eventually performs the function of QUIT again. It looks like this reference implementation does not meet the specification in the presence of the Exception word set.

Another case is when the input source cannot be read. It's probably an ambiguous condition and a system may do anything, for example, it can return control from QUIT, and then the corresponding CATCH will return control with the throw code 0.

[SirWumpus]

... THROW can perform the function of CORE ABORT ...

I don't see how THROW can perform the function of ABORT (Core or Extension). It is the xt that CATCH executes (ABORT or QUIT, or other (user) word that might empty the return stack) well before a THROW might be reached. Am I overlooking something in the current draft?

QUIT doesn't empty the exception stack ...

While QUIT does not empty the exception stack, yet 9.3.3 Exception Stack states "It may be, but need not be, implemented using the return stack." so QUIT could interfere with the exception stack in such an implementation. Even if the exception stack is separate, when CATCH executes QUIT's xt, the return stack is emptied losing the return address and will never return (unless QUIT does something special when there is a catch frame). I feel there is something missing either in QUIT definition and/or rationale to address these concerns.

This ties into my other question #116 as to whether QUIT ever THROWs explicitly like ABORT exception extension, .ie when QUIT completes it does -56 THROW, which might be interesting to CATCH.

[ruv]

Concerning ABORT

how THROW can perform the function of ABORT (Core or Extension). It is the xt that CATCH executes

When a Forth system provides the Exception word set, it shall provide the updated version of ABORT (EXCEPTION ABORT), instead of CORE ABORT. Namely, the definition of ABORT shall be equivalent to : abort -1 throw ;. This ABORT does not empties the return stack unconditionally.

The code ' abort catch is equivalent to :noname -1 throw ; catch. When THROW is performed in this case, it doesn't empties the return stack since there is a user-defined exception frame.

The code ' abort execute is equivalent to -1 throw. When THROW is performed in this case, it empties the return stack (when it performs the function of CORE ABORT, and in turns the function of CORE QUIT) since there is no a user-defined exception frame.

I talk about user-defined exception frames since the system's exception frames (if any) are under the hood and cannot be detected by a program — it doesn't matter whether they are exist on the exception stack or not at the moment.

Concerning QUIT

when CATCH executes QUIT's xt, the return stack is emptied losing the return address and will never return

Yes, but then such QUIT when it's called by CATCH will break the function of THROW . It's a bug in the specification for QUIT in the presence of Exception word set, I think (I have asked for clarification).

When a system provides the Exception word set, it usually implements QUIT which does not empty the return stack, but only restore it's depth. A standard program cannot detect this difference, so such implementation doesn't violate the Standard.

[SirWumpus]

Namely, the definition of ABORT shall be equivalent to : abort -1 throw ;. This ABORT does not empties the return stack unconditionally.

I can accept that data and return stacks are not emptied unconditionally, it makes some sense, and probably desired, but ABORT is meant to perform QUIT in some fashion, and there is another side-effect of QUIT being overlooked:

... store zero in SOURCE-ID if it is present, make the user input device the input source ...

ABORT and QUIT are the only ways to restore standard input; should that be ignored too? Restoring standard input might be desired though, consider:

SAVE-INPUT
\ interpret standard input until EOF or BYE
' ABORT CATCH DROP
RESTORE-INPUT

[ruv]

but ABORT is meant to perform QUIT in some fashion

Once again: ABORT from the Exception word set doesn't perform QUIT when there is a user's exception frame on the exception stack.

\ interpret standard input until EOF or BYE

BYE halts the system. And as it appears, in many systems QUIT also halts the system on EOF. So QUIT cannot be used to take control back when the standard input ends.

[SirWumpus]

From 3 Usage requirements it states:

A system shall provide all of the words defined in 6.1 Core words and 9 The Exception word set.

This says to me that the Exception Word set is not optional, which begs the question why not make section 9 part of the Core in the first place?

Now if one can provide the Exception word set, it seems trivial to include the Exception Extension words, which currently only affect ABORT and ABORT" which also begs the question why an (optional) extension vs just make it part of section 9 Exception words.

Seems very confusing and problematic for a standard to define multiple behaviours when the objective is portability and consistency [suppose this more a criticism of the standard in general, than the current topic].

[ruv]

From 3 Usage requirements it states:

A system shall provide all of the words defined in 6.1 Core words and 9 The Exception word set.

This says to me that the Exception Word set is not optional,

Yes, in the next version of the standard. Your citation is from a draft version.

which begs the question why not make section 9 part of the Core in the first place?

Probably then it's better structured. But the CORE ABORT and CORE ABORT" should be removed in any case, and the specification for THROW should be rewritten. This is a work in progress.

Seems very confusing and problematic for a standard to define multiple behaviours when the objective is portability and consistency [suppose this more a criticism of the standard in general, than the current topic].

It was done in 1994, and I'm sure there was a ground for that, but now it's just a history. In Forth-2012 these parts were not changed. Now it can be made better in the next version of the Standard.