Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Ruvim <ruvim.pinka@gmail.com>
Newsgroups: comp.lang.forth
Subject: Re: QUIT and ABORT
Date: Sat, 17 May 2025 15:30:17 +0400
Organization: A noiseless patient Spider
Lines: 95
Message-ID: <1009s09$c9ih$1@dont-email.me>
References: <87bjtn2hct.fsf@gmail.com>
 <b78a04cbc0fc7c0a6c041e46ea83dc7a6206e5d6@i2pn2.org>
 <2025May4.153331@mips.complang.tuwien.ac.at>
 <6a9a2b6e873c1b72bdec2c72749ef0aac6f33f42@i2pn2.org>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 17 May 2025 13:30:19 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="73c407814ab80c181e12a4348ac9877e";
	logging-data="403025"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+fUaXV85zicVUcYpjnpb11"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:EjjZ0ZQ4gugRq7F4YAdVwjLPLME=
In-Reply-To: <2a3f2365e393969d8de858651cc9486806e2ad12@i2pn2.org>
Content-Language: en-US
Bytes: 5029

On 2025-05-17 06:56, dxf wrote:
> On 16/05/2025 9:12 pm, Ruvim wrote:
>> On 2025-05-16 12:19, dxf wrote:
>>> On 16/05/2025 3:53 pm, Ruvim wrote:
>>>> On 2025-05-15 06:14, dxf wrote:
>>>>> ...
>>>>>
>>>>> CATCH has already done the damage.  It would be naive for a programmer
>>>>> to assume he can re-throw QUIT and it will be as if nothing ever happened.
>>>>
>>>> My point is that such a word is completely useless.
>>>
>>> The goal is catching fish.  What happens to the ones you catch and then
>>> decide to throw it back in is relatively minor.  If they end up a bit
>>> worse for wear that's just how it is.
>>
>> Could you please provide a practical use case for this? The standard `quit` is useful for debugging, at the least.
>>
>> If your goal is to catch `quit` in your program, just redefine `quit` accordingly. Then, of course, the system is not a standard Forth system after loading your program (see 4.2.2).
>>
>>
>>
>>>>> Presumably an implementer of a catchable QUIT actually wants it caught.
>>>>> The question then is what can he do for the occasions when he wants it
>>>>> impervious to CATCH and there are solutions for that.
>>>>>
>>>>
>>>> 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.

Yes, in some scenarios (such as interactive work) you may prefer this 
behavior, but for *any* uncaught exceptions. So, special handling of 
`-56` won't help you at all.



>>>   The application programmer then has the option of making QUIT
>>> catchable by defining:
>>>
>>>     : QUIT -56 THROW ;
>>>
>>
>> But this option already exists. There is no need to specially handle `-56` in `throw`.
> 
> By that argument there's no reason to specially handle -1 in THROW.
> 

As I already mentioned, there are no special handling, it only specifies 
error messages:

   -1 — the empty message (no message);
   -2 — a program-defined message (from last executed `abort"`);
   any other — an implementation defined message concerning the error 
conditions.

Except for the message text, all actions are the same regardless of the 
error code.


--
Ruvim