Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.lang.forth    |    Forth programmers eat a lot of Bratwurst    |    117,927 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 117,313 of 117,927    |
|    dxf to Ruvim    |
|    Re: QUIT and ABORT    |
|    09 May 25 18:20:52    |
      From: dxforth@gmail.com              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.              --- SoupGate-DOS v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca