From: ruvim.pinka@gmail.com
On 2025-05-08 15:01, albert@spenarnc.xs4all.nl wrote:
> In article ,
> 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.
>
> I introduced `break that does deviate from `QUIT only in not cleaning
> the return stack. So you can debug from such a nested "shell" with
> impunity. A soon as you type ^D into this shell, you can continue
> as if nothing happened. Or you can amend the stack, maybe even the
> return stack, is you know what you're doing.
>
> Of course `break must save and restore the current input stream.
> I have words for that. It is straightforward. Others have
> proposed INTERPRET-WHILE-READING or some such words.
> Maybe these words could define a `break, but not as easily.
>
> : break
> SAVE
> BEGIN '(ACCEPT) CATCH DUP E_BROKEN_PIPE <> WHILE
> ?ERRUR SET-SRC INTERPRET REPEAT
> DROP RESTORE
> ;
>
> : QUIT
> POSTPONE [
> BEGIN
> R0 @ RSP! \ this part is missing from break.
> '(ACCEPT) CATCH DUP E_BROKEN_PIPE = IF
> BYE THEN
> ?ERRUR 1+ SET-SRC INTERPRET OK AGAIN
> ;
In this implementation, the following actions of 6.1.2050 `QUIT` are missed:
- store zero in SOURCE-ID if it is present,
- make the user input device the input source.
--
Ruvim
--- SoupGate-DOS v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
