From J.Reid@letterbox.rl.ac.uk Tue Aug 23 18:50:14 1994 Received: from ib.rl.ac.uk by dkuug.dk with SMTP id AA07221 (5.65c8/IDA-1.4.4j for ); Tue, 23 Aug 1994 18:50:14 +0200 Received: from letterbox.rl.ac.uk by ib.rl.ac.uk (IBM VM SMTP V2R1) with TCP; Tue, 23 Aug 94 17:49:42 BST Received: from jkr.cc.rl.ac.uk by letterbox.rl.ac.uk with SMTP (PP) id ; Tue, 23 Aug 1994 16:44:08 +0100 Received: by jkr.cc.rl.ac.uk (4.1/SMI-4.1) id AA03169; Tue, 23 Aug 94 16:46:21 BST Date: Tue, 23 Aug 94 16:46:21 BST From: jkr@letterbox.rl.ac.uk (John Reid) Message-Id: <9408231546.AA03169@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: ENABLE X-Charset: ASCII X-Char-Esc: 29 I have written a note to IFIP WG 2.5 to tell them what happened in Edinburgh, including a summary of the main changes made to the proposal. In case others find it helpful, here is that list. 1. No user-chosen condition names. This is because it was felt that in the long term (Fortran 2000?) they should have local scope, but adding condition names with local scope is too big a change to the standard for the 95 revision. In association with this, the intrinsic condition names have the same scoping rules as intrinsic procedures. 2. Allow the handle statement to name conditions to be handled in addition to those enabled in the enable block. Example 9 in the paper illustrates how useful this can be. 3. Remove the RESIGNAL statement since the effect is identical to the pair ENABLE; END ENABLE. 4. Make the signaling of allocation and i/o conditions outside enable constructs be processor dependent. This allows the processor to do an immediate stop, as now, or to signal only if the condition is enabled somewhere in the call chain. 5. Add a SYSTEM_ERROR condition to cover other (processor-defined) things. 6. Reorganization of the grouping of conditions into combinations (see end of paper). Regards, John.