In article <5069a2ba51509e4f92ffa680982a4e353ec45ab8@i2pn2.org>,
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. Besides BYE is an optional tool
>and I've no idea what use is a catchable EXIT .
>> `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 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?
>
>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.
>
The whole discussion is pointless. The starting point should be what
is the central interpretation loop. I find QUIT a suitable candidate,
but if one is of a different opinion, one should say so.
This is a requirement for a sensible discussion what ABORT THROW and
whatnot are supposed to do with regards to the central interpretation
loop.
The first thing one should do separate the two cases:
1. there is a CATCH/THROW handler
2. there is no CATCH/THROW handler
Another question that arises: are there multiple interpretation loops?
If there are, you cannot ignore this in the discussion.
Abstract discussion like this could occur in discussing algol68, pascal
or haskell, not so much in discussing Forth.
Groetjes Albert
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.
--- SoupGate-DOS v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
