Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: dxf <dxforth@gmail.com>
Newsgroups: comp.lang.forth
Subject: Re: QUIT and ABORT
Date: Sun, 18 May 2025 12:58:02 +1000
Organization: i2pn2 (i2pn.org)
Message-ID: <5ddd51973a3f163595605432f497ac65a5ed1336@i2pn2.org>
References: <87bjtn2hct.fsf@gmail.com> <vvashh$ra84$1@dont-email.me>
 <60caba147f217f0c677ddc6bf8a7492a3c69688b@i2pn2.org>
 <2025May6.091324@mips.complang.tuwien.ac.at>
 <f3783e59aec9762f3871cfb39f36c514dc05f214@i2pn2.org>
 <vvg6l5$12kee$1@dont-email.me>
 <35ba145b7baa62154479eac080a2f6995b24b8e8@i2pn2.org>
 <vvi9b5$1ogea$1@dont-email.me>
 <0c4bc1ac6f9595ebc81448f21aade5d54639ada9@i2pn2.org>
 <vvk6s9$2jjoh$1@dont-email.me>
 <5069a2ba51509e4f92ffa680982a4e353ec45ab8@i2pn2.org>
 <vvlke3$2neud$1@dont-email.me> <vvvlin$1rk75$1@dont-email.me>
 <696f4a3105690a7ea898d1778a37d345cbd4c598@i2pn2.org>
 <1001gaa$2b9mr$2@dont-email.me>
 <9d4eb41927bc7282d1568054a0d94b5a0f60056b@i2pn2.org>
 <1006jsi$3js21$1@dont-email.me>
 <e32f5681efc287a2089300a61fc8db21d04ff7d0@i2pn2.org>
 <10076jg$3nh2i$1@dont-email.me>
 <2a3f2365e393969d8de858651cc9486806e2ad12@i2pn2.org>
 <1009s09$c9ih$1@dont-email.me>
 <4481f037e7bf4a8d7faa59640a9dcfac01c42226@i2pn2.org>
 <100b23g$g4a6$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 18 May 2025 02:58:07 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="825595"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="XPw7UV90Iy7EOhY4YuUXhpdoEf5Vz7K+BsxA/Cx8bVc";
User-Agent: Mozilla Thunderbird
Content-Language: en-GB
In-Reply-To: <100b23g$g4a6$1@dont-email.me>
X-Spam-Checker-Version: SpamAssassin 4.0.0

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.

>> 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

> In many systems, the actions specified for `throw` when there is no user exception frame are implemented in `quit`:
> 
>   : translate-input ( any -- any )
>     begin refill while interpret ?ok repeat
>   ;
>   : quit ( i*x -- never )   \ point (1)
>     rdepth rndrop \ empty the return stack and exception stack
>     0 set-source-id
>     begin
>       0 state ! \ enter interpretation state
>       ['] translate-input catch dup
>     while ( i*x n\0 )   \ point (2)
>       ['] print-error catch if 6 bye-status then
>       depth ndrop \ empty the data stack (and control-flow stack)
>       fdepth fndrop \ empty the floating-point stack
>     repeat bye \ end of stdin
>   ;
> 
> (this is allowed as the programs are not affected)
> 
> And the system enters `quit` right after startup. So `throw` does not call `(core-quit)`, but non-locally *returns* to `(core-quit)` according to the system's exception frame.
> 
> This approach avoids the need to determine in `throw` whether a user exception frame exists, and allows to use `catch` in the words like `evaluate` and `included` to restore the input source. See an example implementation for `throw` in E.9.6.1.2275
> <https://forth-standard.org/standard/implement#imp:exception:THROW>
> 
> 
> The caveat/nuance is that the special handling of `-56` as in your example is not compatible with this approach at all.
>
> This handling cannot be implemented in `throw`, since some exception frame always exists when `throw` is executed. And this handling cannot be implemented in `quit` because in the point (2) the data stack depth is already restored and is the same as in the point (1) plus one.
> 
> That's why I said this special handling of `-56` complicates implementations.

That's hardly my problem or ANS'.  ANS made provision for a catchable QUIT.
It happens I could easily add it.  Those that want it will find a way.