Re: QUIT and ABORT

On 2025-05-09 12:20, dxf wrote:

On 9/05/2025 4:20 pm, Ruvim wrote:

On 2025-05-09 04:54, dxf wrote:

On 8/05/2025 10:50 pm, Ruvim wrote:

On 2025-05-08 06:52, dxf wrote:

On 8/05/2025 3:52 am, Ruvim wrote:

...
I use `quit` only for testing and debugging. And I expect to get into the Forth text interpreter (Forth shell) exactly in the current program state (as far as possible).
>
If `quit` simply calls `-56 throw`, the program state will probably change (due to actions after `catch` in the program, including restoring the data stack depth in `throw`) when you get into the Forth shell. Also, there is a chance that you will not get into the Forth shell at all if the program does not re-throw the error in some places.
>
So I would not recommend the suggested deviation in the `quit` behavior even for new implementers, since this brakes the well-known expectation from `quit`. A better way is to introduce another word with desired behavior deviation.

>
ANS never gave a rationale for ABORT ABORT" QUIT - only
options that we're now exploring.
>
For the reasons you've stated I'm reluctant to define:
>
: QUIT -56 THROW ;
>
But are there reasons an application might were THROW able
to handle it?

>
I don't see such a reason. The application can simply do
`abort` or `-56 throw` (and no special cases are needed).

>
Yes but those would be workarounds.  It's making the argument
QUIT can't or shouldn't be caught whereas I'm talking about
entitlement.

>
`BYE` and `EXIT` cannot be caught too.

 QUIT is in the table; those are not.

The table only states that the code -56 is *reserved* for "QUIT". But -56 is not specified anywhere else, so this lonely reservation does not entail any formal consequences.

Besides BYE is an optional tool
and I've no idea what use is a catchable EXIT .

No use. Ditto for catchable `BYE` (if any) or any other immediate termination.

`QUIT` can be considered by the Forth program as a kind of `BYE` that
immediately returns control to the Forth shell (when `BYE` returns control
to the host OS).
>
>

Speaking of entitlement, ANS made EXCEPTION EXT a one-way street.
There's no rolling back from the changes.

>
If you mean that EXCEPTION EXT is not actually optional in itself,
but must be provided if EXCEPTION is provided — yes, I agree.

 Not what I said

I wonder what you meant by "ANS made EXCEPTION EXT a one-way street".

but if you're going to enforce a catchable ABORT and
ABORT" then why omit QUIT - and if you do - why is it in table?

I think, `QUIT` is in the table by a mistake.
Regarding `ABORT` and `ABORT"` (and many other in Forth-2012) — they should not go into this table since this table formally reserves throw codes for *ambiguous conditions* only.

We can keep going round in circles but ISTM what's needed is a rationale.
Because I'm not seeing one in ANS.  Folks have implemented what it said
but can't explain it.  Hence the Bible allusion.
 

Perhaps you could write the rationale?
--
Ruvim