Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!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: Fri, 9 May 2025 23:18:27 +0400
Organization: A noiseless patient Spider
Lines: 88
Message-ID: <vvlke3$2neud$1@dont-email.me>
References: <87bjtn2hct.fsf@gmail.com>
 <nnd$595f502c$48101358@27425914746d2863>
 <d9149a9d12db559e2720156b315fcfdcdd90e3fe@i2pn2.org>
 <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 09 May 2025 21:18:28 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="983a1cec72bc46a8db52b3bd128f7a43";
	logging-data="2866125"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/nc6qOhu18CXGX8KhFW9+M"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:DLuttapYMMAPw4tdEO+IXVkQdxk=
In-Reply-To: <5069a2ba51509e4f92ffa680982a4e353ec45ab8@i2pn2.org>
Content-Language: en-US
Bytes: 5156

On 2025-05-09 12:20, dxf wrote:
> On 9/05/2025 4:20 pm, Ruvim wrote:
>> On 2025-05-09 04:54, dxf wrote:
>>> On 8/05/2025 10:50 pm, Ruvim wrote:
>>>> 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).
>>>
>>> Yes but those would be workarounds.  It's making the argument
>>> QUIT can't or shouldn't be caught whereas I'm talking about
>>> entitlement.
>>
>> `BYE` and `EXIT` cannot be caught too.
> 
> QUIT is in the table; those are not.

The table only states that the code -56 is *reserved* for "QUIT". But 
-56 is not specified anywhere else, so this lonely reservation does not 
entail any formal consequences.



> Besides BYE is an optional tool
> and I've no idea what use is a catchable EXIT .

No use. Ditto for catchable `BYE` (if any) or any other immediate 
termination.




>> `QUIT` can be considered by the Forth program as a kind of `BYE` that
>> immediately returns control to the Forth shell (when `BYE` returns control
>> to the host OS).
>>
>>
>>> Speaking of entitlement, ANS made EXCEPTION EXT a one-way street.
>>> There's no rolling back from the changes.
>>
>> If you mean that EXCEPTION EXT is not actually optional in itself,
>> but must be provided if EXCEPTION is provided — yes, I agree.
> 
> Not what I said 

I wonder what you meant by "ANS made EXCEPTION EXT a one-way street".


> but if you're going to enforce a catchable ABORT and
> ABORT" then why omit QUIT - and if you do - why is it in table?

I think, `QUIT` is in the table by a mistake.


Regarding `ABORT` and `ABORT"` (and many other in Forth-2012) — they 
should not go into this table since this table formally reserves throw 
codes for *ambiguous conditions* only.



> We can keep going round in circles but ISTM what's needed is a rationale.
> Because I'm not seeing one in ANS.  Folks have implemented what it said
> but can't explain it.  Hence the Bible allusion.
> 

Perhaps you could write the rationale?



--
Ruvim