From: dxforth@gmail.com
On 4/05/2025 11:33 pm, Anton Ertl wrote:
> dxf writes:
>> On 4/05/2025 2:02 am, Anton Ertl wrote:
>>> dxf writes:
>>>> Checking the doc it says:
>>>>
>>>> 9.3.5 Possible actions on an ambiguous condition
>>>>
>>>> A system choosing to execute THROW when detecting one of the ambiguous
>>>> conditions listed in table 9.3.6 shall use the throw code listed there.
>>>
>>> Calling ABORT or QUIT is not an ambiguous condition, so that section
>>> plays no role there.
>>
>> Yet ABORT ABORT" and QUIT are present in the table and assigned codes.
>
> For ABORT the section 9.6.2.0670 specifies that it performs a -1
> THROW. While -1 happens to be the value shown in table 9.1 as being
> reserved for ABORT, there is no ambiguous condition involved here.
> Likewise for -2, ABORT" and section 9.6.2.0680.
If and only if EXCEPTION EXT is implemented are those mandatory. Otherwise
they are optionally CATCHable at the implementer's discretion per section
9.3.5 above.
> So table 9.1 is useful beyond the purpose of assigning throw codes to
> ambiguous conditions. However, for QUIT there is no redefinition in
> chapter 9.
Again only because ANS hadn't specified QUIT as mandatory. For all I know
it was because it would have killed the QUIT-based exception handler ANS
offered. To not include QUIT in Table 9.2 would have raised questions as
to why not.
>> It is clear to me all three are candidates for CATCHing and that this
>> was the intent.
>
> It may have been the intent of adding the -56 throw code to also have
> a corresponding redefinition of QUIT in Chapter 9, but they did not
> follow through on it. Maybe because -56 THROW changes the data stack
> depth while QUIT does not.
That's a bundle of maybe's. I believe I've given an explanation that
requires no suppositions.
>> This is confirmed by the EXCEPTION EXT wordset in which
>> ABORT and ABORT" are required to be CATCHable irrespective of their
>> category.
>
> Category?
ABORT ABORT" QUIT not being exceptions
> A system that implements 9.6.2.0670 makes ABORT catchable, and a
> system that implements 9.6.2.0680 makes ABORT" catchable. I find it
> perverse that these words are in Exception ext, so you could have a
> system that has CATCH, but an uncatchable ABORT and/or an uncatchable
> ABORT". And for QUIT, the standard as it is does not have a catchable
> variant at all.
In fact all of the conditions listed in Table 9.2 are optional. Only
CATCH and THROW are mandatory. I read that to mean a standard program
can only rely on positive codes it has specified itself.
>>>> : QUIT -56 THROW ;
>>>
>>> That would not be a standard system, because in a standard system QUIT
>>> must do what 6.1.2050 QUIT says, and "-56 THROW" is not a correct
>>> implementation of that.
>>
>> No for the fact QUIT is CATCHable by virtue of its inclusion in the table
>> of codes in Section 9.
>
> There is nothing in the standard that makes such a connection (unlike
> for ABORT and ABORT"). I don't know for what purpose -56 was added to
> the table, > but I know (and we have the proposal text) for what purpose
> -59 (ALLOCATE) was added to the table, and it was not with the intent
> of redefining ALLOCATE as
>
> : ALLOCATE -59 THROW ;
>
> So obviously it's just your interpretation of the table that if the
> description of a throw code C contains a word name W, systems
> implementing the exception wordset are free to redefine W as throwing
> C.
Again it's an interpretation that fits what is present in ANS.
> ...
--- SoupGate-DOS v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
