Liste des Groupes | Revenir à cl forth |
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).
If you need the Forth shell in the application data stack and state — do `quit`. If you need to break the application execution — do `abort`.
Probably, the external signal SIGTERM can be transferred to `-56 throw` in the Forth system, and the external signal SIGINT (Ctrl+C) can be transferred to `-28 throw`.
It's arguable ANS left the door open. Just because the spec for THROW didn't
special-case -56 doesn't mean an implementer can't.
The implementer can special-case -56 (as well as anything else) only to the extent that it does not affect a standard program.
--
Ruvim
Les messages affichés proviennent d'usenet.