Re: QUIT and ABORT

On 2025-05-14 05:52, dxf wrote:

On 14/05/2025 12:39 am, Ruvim wrote:

>
[...]
>

but if you're going to enforce a catchable ABORT and
ABORT" then why omit QUIT

>
One more argument. If `QUIT` is catchable like `ABORT` then it:
- either behaves the same as `ABORT` (empties or restores the data stack depth);
- or does not predict the data stack at all when it starts the Forth text interpreter (because the data stack depth will be set according to the earliest/deepest user exception frame).

 Here's how it would work in my system were I to add it:
 If 'QUIT' is catchable then the functionality that was CORE QUIT will exist
under another name (or be nameless if the implementer so chooses).  Then
 - if QUIT is not caught it performs the *functionality* described
   in CORE QUIT.

So, in this case there is no difference with the standardized behavior.

 - if QUIT is caught then the stack point is determined by CATCH.

In most use cases the exception is rethrown after `catch` and eventually you will get into the Forth text interpreter with some random values on the data stack if the exception code is -56, and no values otherwise. This is useless and inconsistent. Therefore, the standardized behavior of `QUIT` is better.

 - if ABORT is not caught it clears the data stack and performs the
   *functionality* described in CORE QUIT.

So you end up in the Forth text interpreter with the empty data stack.

 - if ABORT is caught then the stack point is determined by CATCH.

And if the exception is rethrown after `catch`, you end up in the Forth text interpreter with the empty data stack too.
So, whether the exception was rethrown or there was no user exception frame at all, the result is the same.
--
Ruvim