From: anton@mips.complang.tuwien.ac.at   
      
   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.   
      
   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.   
      
   >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.   
      
   >This is confirmed by the EXCEPTION EXT wordset in which   
   >ABORT and ABORT" are required to be CATCHable irrespective of their   
   >category.   
      
   Category?   
      
   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.   
      
   >>> : 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.   
      
   >If OTOH you believe the inclusion of ABORT ABORT"   
   >and QUIT was made in error then you have the option of testing that by   
   >making a proposal to have them removed.   
      
   The throw codes -1 and -2 were obviously added due to 9.6.2.0670 and   
   9.6.2.0680, not at all in error. I do not know why -56 was added, but   
   it does not hurt, and existing programs might use it, so there is no   
   good reason to remove it from the table.   
      
   Admittedly, the presence in the table results in no guarantees from   
   the standard, so removing the entry for -56 would not really hurt,   
   either. In any case, such a proposal would only poll the opinion of   
   the current committee, so it's not a way to find out whether the   
   Forth-94 committee consider the addition of -56 to the table as a   
   mistake.   
      
   If someone made a proposal to the committee, existing practice would   
   probably be considered more important than whatever we can still   
   determine about the intent of the Forth-94 committee. I don't know a   
   way to determine how many programs there are around that expect QUIT   
   to be catchable, or that expect it not to be catchable, but for   
   systems we can check relatively easily what they do:   
      
   Here's the code I give to the Forth systems:   
      
   1 .( a ) cr -56 throw .( b )   
   .s   
   2 .( a ) cr quit .( b )   
   .s   
   : foo 3 -56 throw ; ' foo catch 5   
   .s   
   : bar 4 quit ; ' bar catch 6   
   .s   
      
   Let's see what different Forth systems do:   
      
   Gforth 0.7.9_20250409   
   1 .( a ) cr -56 throw .( b ) a   
      
   *the terminal*:1:17: error: QUIT   
   1 .( a ) cr -56 >>>throw<<< .( b )   
   .s <0> ok   
   2 .( a ) cr quit .( b ) a   
      
   .s <1> 2 ok 1   
   : foo 3 -56 throw ; ' foo catch 5 ok 3   
   .s <3> 2 -56 5 ok 3   
   : bar 4 quit ; ' bar catch 6   
   .s <4> 2 -56 5 4 ok 4   
      
      
   iForth 5.1-mini   
   FORTH> 1 .( a ) cr -56 throw .( b ) a   
      
   FORTH> .s   
    Data: ---   
   System: ---   
    Float: --- ok   
   FORTH> 2 .( a ) cr quit .( b ) a   
      
   [1]FORTH> .s   
    Data: 2 ---   
   System: ---   
    Float: --- ok   
   [1]FORTH> : foo 3 -56 throw ; ' foo catch 5   
   [1]FORTH> .s   
    Data: 2 ---   
   System: ---   
    Float: --- ok   
   [1]FORTH> : bar 4 quit ; ' bar catch 6   
   [2]FORTH> .s   
    Data: 2 4 ---   
   System: ---   
    Float: --- ok   
      
   SwiftForth x64-Linux 4.0.0-RC89 15-Jul-2024   
   1 .( a ) cr -56 throw .( b ) a   
   QUIT   
   .s   
   <-Top ok   
   2 .( a ) cr quit .( b ) a   
   .s   
   2 <-Top ok   
   : foo 3 -56 throw ; ' foo catch 5 ok   
   .s   
   2 -56 5 <-Top ok   
   : bar 4 quit ; ' bar catch 6 .s   
   2 -56 5 4 <-Top ok   
      
   VFX Forth 64 5.43 [build 0199] 2023-11-09 for Linux x64   
      
   1 .( a ) cr -56 throw .( b ) a   
      
   No text available for THROW code -56(10)   
    -> 1 .( a ) cr -56 throw .( b )   
    ^   
   .s   
   DATA STACK   
   empty stack   
    ok   
   2 .( a ) cr quit .( b ) a   
      
   .s   
   DATA STACK   
    top   
    2 0000:0000:0000:0002   
    ok-1   
   : foo 3 -56 throw ; ' foo catch 5 ok-3   
   .s   
   DATA STACK   
    top   
    5 0000:0000:0000:0005   
    -56 FFFF:FFFF:FFFF:FFC8   
    2 0000:0000:0000:0002   
    ok-3   
   : bar 4 quit ; ' bar catch 6   
   .s   
   DATA STACK   
    top   
    4 0000:0000:0000:0004   
    5 0000:0000:0000:0005   
    -56 FFFF:FFFF:FFFF:FFC8   
    2 0000:0000:0000:0002   
      
   So Gforth, SwiftForth, and VFX behave the same way: QUIT is not   
   catchable, while -56 THROW is; QUIT does not produce output, while an   
   uncaught -56 THROW results in output from the system.   
      
   In iForth 5.1-mini QUIT preserves the stack while an uncaught -56   
   THROW resets it to empty (as it should); the uncaught -56 THROW does   
   not produce a message. For the cases with CATCH, the FOO variant does   
   not put the -56 on the stack and does not text-interpret the 5   
   afterwards, but it does preserve the 2 that was pushed earlier.   
   Strange. The BAR variant behaves as expected. If I try   
      
   2 : foo 3 1 throw ; ' foo catch 5   
   .s   
      
   iForth 5.1-mini behaves as follows:   
      
   FORTH> 2 : foo 3 1 throw ; ' foo catch 5 ok   
   [3]FORTH> .s   
    Data: 2 1 5 ---   
   System: ---   
    Float: --- ok   
      
   This is expected, so it seems to do something special for -56 THROW.   
      
   - anton   
   --   
   M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html   
   comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html   
    New standard: https://forth-standard.org/   
   EuroForth 2023 proceedings: http://www.euroforth.org/ef23/papers/   
   EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|