Re: QUIT and ABORT

On 2025-05-08 15:01, albert@spenarnc.xs4all.nl wrote:

In article <vvg6l5$12kee$1@dont-email.me>,
Ruvim  <ruvim.pinka@gmail.com> 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.

 I introduced `break that does deviate from `QUIT only in not cleaning
the return stack. So you can debug from such a nested "shell" with
impunity. A soon as you type ^D into this shell, you can continue
as if nothing happened. Or you can amend the stack, maybe even the
return stack, is you know what you're doing.
 Of course `break must save and restore the current input stream.
I have words for that. It is straightforward. Others have
proposed INTERPRET-WHILE-READING or some such words.
Maybe these words could define a `break, but not as easily.
 : break
     SAVE
     BEGIN '(ACCEPT)   CATCH   DUP   E_BROKEN_PIPE <>   WHILE
     ?ERRUR   SET-SRC   INTERPRET   REPEAT
     DROP   RESTORE
;
 : QUIT
     POSTPONE [
     BEGIN
     R0   @   RSP!   \ this part is missing from break.
     '(ACCEPT)   CATCH   DUP   E_BROKEN_PIPE =   IF
     BYE   THEN
     ?ERRUR   1+   SET-SRC   INTERPRET   OK   AGAIN
;

In this implementation, the following actions of 6.1.2050 `QUIT` are missed:
   - store zero in SOURCE-ID if it is present,
   - make the user input device the input source.
--
Ruvim