Re: QUIT and ABORT

On 2025-05-15 06:14, dxf wrote:

On 14/05/2025 5:21 pm, Ruvim wrote:

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.

 CATCH has already done the damage.  It would be naive for a programmer
to assume he can re-throw QUIT and it will be as if nothing ever happened.

My point is that such a word is completely useless.

 

- 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?  An empty data stack is what CORE ABORT does.

Yes, I brought this up just to show below that the result is the same.

>
So, whether the exception was rethrown or there was no user exception frame at all, the result is the same.

 Presumably an implementer of a catchable QUIT actually wants it caught.
The question then is what can he do for the occasions when he wants it
impervious to CATCH and there are solutions for that.
 

What solution do you mean?
--
Ruvim