Re: QUIT and ABORT

In article <5069a2ba51509e4f92ffa680982a4e353ec45ab8@i2pn2.org>,
dxf  <dxforth@gmail.com> 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.  Besides BYE is an optional tool
and I've no idea what use is a catchable EXIT .

`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 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?
>
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.
>

The whole discussion is pointless. The starting point should be what
is the central interpretation loop. I find QUIT a suitable candidate,
but if one is of a different opinion, one should say so.
This is a requirement for a sensible discussion what ABORT THROW and
whatnot are supposed to do with regards to the central interpretation
loop.
The first thing one should do separate the two cases:
1. there is a CATCH/THROW handler
2. there is no CATCH/THROW handler

Another question that arises: are there multiple interpretation loops?
If there are, you cannot ignore this in the discussion.

Abstract discussion like this could occur in discussing algol68, pascal
or haskell, not so much in discussing Forth.

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.