From: ruvim.pinka@gmail.com   
      
   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   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)