Path: 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: Fri, 16 May 2025 09:53:22 +0400
Organization: A noiseless patient Spider
Lines: 66
Message-ID: <1006jsi$3js21$1@dont-email.me>
References: <87bjtn2hct.fsf@gmail.com>
 <2025May3.072517@mips.complang.tuwien.ac.at>
 <6973d7bc1d0376ab234a39a3dda82287b7b13450@i2pn2.org>
 <2025May3.180226@mips.complang.tuwien.ac.at>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 16 May 2025 07:53:23 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="e1c8b6f4eec558b47b4fdad1c2a8b7f3";
	logging-data="3797057"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+gMQsTz01VKgVaW9wdBUnK"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:6btrXoVP7UCG0qvp6F1dU77SSsY=
Content-Language: en-US
In-Reply-To: <9d4eb41927bc7282d1568054a0d94b5a0f60056b@i2pn2.org>

On 2025-05-15 06:14, dxf wrote:
> On 14/05/2025 5:21 pm, Ruvim wrote:
>> On 2025-05-14 05:52, dxf wrote:
>>> On 14/05/2025 12:39 am, Ruvim wrote:
>>>>
>>>> [...]
>>>>
>>>>>> but if you're going to enforce a catchable ABORT and
>>>>>> ABORT" then why omit QUIT
>>>>
>>>> One more argument. If `QUIT` is catchable like `ABORT` then it:
>>>> - either behaves the same as `ABORT` (empties or restores the data stack depth);
>>>> - or does not predict the data stack at all when it starts the Forth text interpreter (because the data stack depth will be set according to the earliest/deepest user exception frame).
>>>
>>> Here's how it would work in my system were I to add it:
>>>
>>> If 'QUIT' is catchable then the functionality that was CORE QUIT will exist
>>> under another name (or be nameless if the implementer so chooses).  Then
>>>
>>> - if QUIT is not caught it performs the *functionality* described
>>>     in CORE QUIT.
>>
>> So, in this case there is no difference with the standardized behavior.
>>
>>
>>>
>>> - if QUIT is caught then the stack point is determined by CATCH.
>>
>> In most use cases the exception is rethrown after `catch` and eventually you will get into the Forth text interpreter with some random values on the data stack if the exception code is -56, and no values otherwise. This is useless and inconsistent. Therefore, the standardized behavior of `QUIT` is better.
> 
> 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.



> 
>>> - if ABORT is not caught it clears the data stack and performs the
>>>     *functionality* described in CORE QUIT.
>>
>> So you end up in the Forth text interpreter with the empty data stack.
>>
>>>
>>> - if ABORT is caught then the stack point is determined by CATCH.
>>
>> And if the exception is rethrown after `catch`, you end up in the Forth text interpreter with the empty data stack too.
> 
> So?  An empty data stack is what CORE ABORT does.

Yes, I brought this up just to show below that the result is the same.

>>
>> So, whether the exception was rethrown or there was no user exception frame at all, the result is the same.
> 
> 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?


--
Ruvim