Re: QUIT and ABORT

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

Irrespective of the merits such a change to the spec for THROW would
be not be practical given most systems appear to use ANS' QUIT-based
exception handler.  But for new implementers or the curious here is
how I organised mine and which is readily changeable.
  \ return to OS with exit code
: RETURN ( code -- ) ... ;
 \ perform ANS QUIT
: (quit) ( -- )  r0 @ rp! reset normal /interpret
   begin cr (refill) drop interpret state? 0= if (vstat)
   @execute then again ;
 \ exit to OS or back to forth
: ?return ( code -- )  turnkey? if return then drop (quit) ;

Returning to OS can be useful not only for a turnkey program, but also for batch mode, in which the Forth system must return to the OS on any uncaught error.
A possible use-case in Linux shell:
   ./generate-forth-program params | forth --batch-mode
since you probably prefer not to interpret the following lines if there an error occurs when defining a word in some line.

 \ clear data stacks
: (abort) ( i*x -- )  s0 @ sp!  fs0 @ fsp !  1 ?return ;
 \ part of THROW
: error ( n -- )
   -1 of (abort) then
   -2 of boot cell+ @ 0= if .error then
      space errmsg 2@ type (abort) then
   ."  THROW #" @base decimal swap . !base (abort) ;
 : QUIT ( -- )  0 ?return ;  \ QUIT not trapped
 \ QUIT is not trapped in DX-Forth but may be made so by
\ adding  -56 of 1 ?return then  to 'error' and defining
\ : QUIT  -56 throw ;

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.

 : ?ABORT ( flag c-addr u -- )
   rot if errmsg 2! -2 throw then 2drop ;
 : (abort") ( flag -- )  r> count 2dup + >r ?abort ;
 : ABORT"  state @ if postpone (abort") ," end
   postpone s" ?abort ; immediate
 : ABORT  -1 throw ;
 

--
Ruvim