Re: QUIT and ABORT

On 18/05/2025 6:16 pm, Ruvim wrote:

On 2025-05-18 06:58, dxf wrote:

On 18/05/2025 8:20 am, Ruvim wrote:

On 2025-05-17 17:28, dxf wrote:

On 17/05/2025 9:30 pm, Ruvim wrote:

On 2025-05-17 06:56, dxf wrote:

On 16/05/2025 9:12 pm, Ruvim wrote:

...
What solution do you mean?

>
Default behaviour of QUIT is Core QUIT.  THROW handles -56 by jumping to
Core QUIT.

>
If you make `throw` do this regardless of whether a user's exception frame exists in the exception stack, you make the `-56` error code uncatchable. So, the following test case will fail:
>
     t{  [: -56 throw ;] catch -> -56 }t
>
And what is the benefit?

>
Why should it fail?

>
You wrote: "THROW handles -56 by jumping to Core QUIT". Then the test should fail. But as you now show, you only meant the case where there is no user exception frame in the exception stack.
>
>

>
     [: -56 throw ;] catch  ok  -56 <
>
     [: -1 throw ;] catch  ok  -1 <

>
Okay, these cases are compliant.
>
>

>
     1 2 3 -56 throw
       ok  1 2 3 <
>
     1 2 3 -1 throw
       ok

>
This special handling of `-56` is inconsistent, not justified by practice, and complicates implementations.

>

>
Well, at least you don't object to the arguments about inconsistency and impracticality.

>
I saw the pejoratives and was waiting for the arguments.

 
Hope, I have given enough arguments now (see also below).
 
Re practice — the burden of proof (providing examples) lies with the one who asserts that it is useful in practice.

 
I only said ANS made provision for it.  It is for the implementer to decide
whether it is useful to them and how to provide it.

Neither special nor complicated:
>
    -1  of s0 @ sp! fs0 @ fsp ! (core-quit) then
>
    -56 of (core-quit) then

>
Why do you empty stacks especially for `-1`?  Don't you do the same for `-2`, `-3`, `-4`, etc?

>
The above was for explanatory purposes.  The actual code is here:
>
https://pastebin.com/FAmufbki

 
An excerpt:
 
: error ( n -- )  \ part of THROW
  -1 of (abort) then
  -2 of boot cell+ @ 0= if .error then
     space errmsg 2@ type (abort) then
  -56 of 1 ?return then
  ."  THROW #" @base decimal swap . !base (abort) ;
 
: THROW ( n -- )
  ?dup if catcher @ ?dup 0= if error then rp!
  r> catcher ! 2r> fsp ! swap >r sp! drop r>  then ;
 
: CATCH ( xt -- n | 0 )
  sp@ fsp @ 2>r catcher @ >r rp@ catcher !
  execute 0 r> catcher ! 2r> 2drop ;
 
End of excerpt.
 
Note that in `error` you don't transfer control to `(abort)` only in the case of `-56`.

I transfer control to (abort) except in the case of -56 where it passes to (quit).

The other differences are only related to the different error messages and can be factored out. For example, an equivalent definition:
 
  : error ( S: n\0 -- never )
    dup print-error
    -56 = if 1 ?return ( S: never ) then
    (abort)  ( S: never )
  ;
 
 
 
Another question is how are `evaluate` and `included` implemented?
 
I assume they use `catch`.

INCLUDE uses CATCH , EVALUATE does not.

Then your Forth system probably shows the following behavior in its terminal:
 
  999 -56 throw
     ok  999 <
 
  s" 999 -56 throw" evaluate
     ok
 
Of course, the first case shows a non-standard behavior.

The first case is correct behaviour for a system that implements a catchable QUIT.
The result of the second case depends upon whether CATCH was involved.

But moreover, the second case means that your catchable `quit` will not keep the data stack when it is called from `evaluate` or `included` (or `load`).
 
And what is the use of this?

It's what I expect from a catchable QUIT.  ANS doesn't compel anyone to implement
a catchable QUIT.  Same as ANS didn't compel anyone to implement a catchable ABORT
or ABORT".  But if you choose to make them catchable, you wear the result.