From J.Reid@letterbox.rl.ac.uk Thu Oct 6 17:13:48 1994 Received: from ib.rl.ac.uk by dkuug.dk with SMTP id AA23771 (5.65c8/IDA-1.4.4j for ); Thu, 6 Oct 1994 17:13:48 +0100 Received: from letterbox.rl.ac.uk by ib.rl.ac.uk (IBM VM SMTP V2R1) with TCP; Thu, 06 Oct 94 17:13:33 BST Received: from jkr.cc.rl.ac.uk by letterbox.rl.ac.uk with SMTP (PP) id ; Thu, 6 Oct 1994 17:10:37 +0100 Received: by jkr.cc.rl.ac.uk (4.1/SMI-4.1) id AA04275; Thu, 6 Oct 94 17:13:10 BST Date: Thu, 6 Oct 94 17:13:10 BST From: jkr@letterbox.rl.ac.uk (John Reid) Message-Id: <9410061613.AA04275@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Enable comments by WG5 member X-Charset: ASCII X-Char-Esc: 29 The anonymous WG5 member who sent comments to Jerry has read the document carefully and I would like to thank him or her. I agree with most of the comments (but not all). Here is the detail. I have removed chunks that are just copies of the enable proposal. John Reid. ............................................................................... > <<2.4.8 Condition>> > > A <> is a default integer flag associated with the > occurrence of an exceptional event. The value 0 corresponds to the > quiet state and this is its initial value. Processor dependent nonzero > values correspond to signaling states. Negative values can occur only > through execution of the SIGNAL > >COMMENT: change 'the SIGNAL' to 'a SIGNAL' to ensure a user doesn't believe there > >COMMENT: can be only one SIGNAL statement in an enable block which 'the' might imply. I agree. > statement. The value may be found by execution of a CONDITION_INQUIRE statement. > >COMMENT: I don't like the use of the word flag, which could be taken to mean a > >COMMENT: two-valued (on and off). Could we find another word, like item or value > >COMMENT: or something. I don't feel very strongly on this though. It is the best word I can think of. > > [Footnote: The reason for specifying that conditions have integer > values is that this leaves open the possibility of providing detailed > information about the condition. This will be useful when a procedure > (for example, in a library) signals a condition so that it can indicate > the cause of the problem. The intrinsic values are forced to be > positive so that a negative value can be seen to be created by source > code and not by the system.] > > [Footnote: Although multitasking is not part of Fortran 90, the > interaction of this proposal with multitasking extensions has been > considered. A model is that each virtual processor has a flag for each > condition. For example, condition handling is permissible within a > pure procedure. Enable, handle, and end-enable statements act as > barriers at which the condition values are merged.] > >COMMENT: Here we say that each virtual processor has a 'flag' and that the > >COMMENT: 'values' are merged. I do not see what is wrong here. > > 22/23+ Add to the Blanks Optional column: > END ENABLE > > 67/39. After 'terminated', add 'unless the ALLOCATION_ERROR condition is enabled'. > > 68/40. After 'terminated', add 'unless the DEALLOCATION_ERROR condition is enabled'. > > 80/2. After 'program', add ', except in an enable block for a suitable condition'. > > >COMMENT: There are very many places in the standard (particularly in chapter > >COMMENT: 13, but also in other places) where this sort of change should be made. > >COMMENT: We should either change them all or change none and put a paragraph > >COMMENT: somewhere general that says that all these sort of restrictions hold > >COMMENT: only when not in an enable block for a suitable condition. > >COMMENT: I prefer the former (i.e. change them all, but someone needs to read > >COMMENT: the whole standard to be sure of finding all of the places. I began the search for places and considered suitable wording, and came to the conclusion that this approach is wrong. There are a large number of places and the changes make the document less readable. I think it is best to regard the document as describing the prohibitions and restrictions of a program with no enable constructs. Exception handling essentially adds an extra layer. I propose that we delete the edit to 80/2 and add the following edit : 3/35. Add An executing program is permitted to violate a prohibition or restriction where this corresponds to a condition (2.4.8) that has been enabled (8.1.5.1) or that the processor signals when not enabled. A probibition or restriction expressed as a constraint to the syntax rules is never relaxed in this way. The intrinsic conditions are specified in 15.1. > > 95/10+ Add > (4) ENABLE construct > > 95/19. Delete 'three'. > > 107/0+. Add > > <<8.1.5 Condition handling>> > > A condition has a name with the same scoping rules as for intrinsic procedures > >COMMENT: change 'procedures' to 'procedure names'. It is the names that have > >COMMENT: scoping rules. I agree. > > The value of each condition handled by the enable construct is set to > the quiet value upon completion of execution of the . > >COMMENT: change 'completion' to 'normal completion'. A signal statement can > >COMMENT: terminate the execution of a handle block, but does not set the handled > >COMMENT: conditions to quiet. I agree. > === > > <<8.1.5.3 Signaling conditions that are not enabled>> > > A processor may signal a condition while executing a statement that is > not in an enable block for the condition. If in a subprogram, a return > is executed without alteration of the values of the conditions. If in > a main program, a stop is executed and the processor must issue a > warning on the default output unit. > >COMMENT: The is no mention of 'default output unit' in the index to the standard. > >COMMENT: At the very least, some words should be added to define this so that an > >COMMENT: index entry is created for it. A word change is needed. My suggestion is 'the unit identified by * in a WRITE statement'. > > [Footnote: On return to the caller, the condition will be signaling. > If the invocation is within an enable block that has a handler for the > condition, there will be a transfer to the handler (or a return or > stop), but not > >COMMENT: Delete '(or a return or a stop)'. If the invocation is within an enable > >COMMENT: block that has a handler for the condition there WILL be a transfer > >COMMENT: to the handler. There will never be a return or a stop. No, the text is correct. The invocation may be within an enable block that does not have a handler for the condition. > necessarily until the execution of the block is complete. If the > invocation is not within an enable block that has a handler for the > condition, there may be a return (or stop) at once, or the processor > may continue executing.] > > > <<8.1.5.4 Signal statement>> > > R835g <> SIGNAL (,) > > Constraint: The must be of type default integer. > > Constraint: If the condition name is that of a combination condition > (15.7), the must be the literal constant 0. > > The SIGNAL statement changes the value of the condition it names to > that of the expression it contains. If the value is nonzero, it causes > a transfer of control. If the statement is in an enable block of an > enable construct that has a handler for the condition, the transfer is > to the handler of the innermost such enable construct. Otherwise, it > is as for a return if in a subprogram, or a stop if in a main program. > > [Footnote: In a handler, the pair of statements > ENABLE > END ENABLE > has a resignaling effect. If any handled condition is signaling, there > will be a transfer of control to an outer handler (or a stop or > return).The values of the conditions are not altered.] > >COMMENT: delete '(or a stop or return)'. If the condition is handled, there WILL > >COMMENT: be a transfer to an outer handler. > No, the text is correct. The condition may be 'handled' without there being a handler for the condition. The hope is that there is a handler somewhere up the call chain. > <<8.1.5.5 Examples of ENABLE constructs>> > > Example 1: > > MODULE MATRIX > ! Module for matrix multiplication of real arrays of rank 2. > INTERFACE OPERATOR(.mul.) > MODULE PROCEDURE MULT > END INTERFACE > CONTAINS > FUNCTION MULT(A,B) > REAL, INTENT(IN) :: A(:,:),B(:,:) > REAL MULT(SIZE(A,1),SIZE(B,2) > >COMMENT: Change '2)' to ''2))' missing right paren Agreed. > ENABLE (INTRINSIC, OVERFLOW) > MULT = MATMUL(A, B) > HANDLE > SIGNAL(INEXACT, -1) > END ENABLE > END FUNCTION MULT > END MODULE MATRIX > > This module provides matrix multiplication for real arrays of rank 2. > Since the condition INSUFFICIENT_STORAGE signals outside enable blocks > (see Section 15.1), if there is insufficient storage for the necessary > temporary array, the module will signal the condition > INSUFFICIENT_STORAGE. If an INTRINSIC or OVERFLOW condition occurs, > the module will signal the condition INEXACT with value -1. > > > Example 6: > > REAL FUNCTION CABS (Z) > COMPLEX Z > ! Calculate the complex absolute value, using a scaled algorithm > ! if the straightforward calculation underflows or overflows. Set the > ! overflow condition to the value -1 if the result is too large to > ! be representable. > > REAL S, ZI, ZR > INTRINSIC REAL, AIMAG, SQRT, ABS, MAX > > ZR = REAL(Z) > ZI = AIMAG(Z) > > quick: ENABLE(OVERFLOW, UNDERFLOW) > > ! This is the quick and usual calculation. > CABS = SQRT(ZR**2 + ZI**2) > > HANDLE quick > > ! Will try again using a scaled equivalent method. > S = MAX(ABS(ZR),ABS(ZI)) > SIGNAL (OVERFLOW,0) ; SIGNAL (UNDERFLOW,0) > slow: ENABLE(OVERFLOW, UNDERFLOW) > CABS = S*SQRT( (ZR/S)**2 + (ZI/S)**2 ) > HANDLE slow > CONDITION_INQUIRE(OVERFLOW,K) > IF (K/= 0) THEN > ! The result is too large to be representable. > SIGNAL(OVERFLOW, -1) > ELSE > CONDITION_INQUIRE(UNDERFLOW,K) > IF (K/= 0) CABS = S > >COMMENT: I think that this code is misleading. How could K possibly be zero. > >COMMENT: The handle only hanndles overflow and underflow, and we have already > >COMMENT: checked that overflow is not signalling, so underflow must be. I agree. Let's delete CONDITION_INQUIRE(UNDERFLOW,K) IF (K/= 0) > END IF > END ENABLE slow > > END ENABLE quick > > END FUNCTION CABS > > This illustrates the setting of a special condition value when the > problemreally has a result that overflows. > > Example 7: > > MODULE LIBRARY > ... > CONTAINS > SUBROUTINE B > ... > X = Y*Z(I) ! No condition enabled. > IF(X>10.)SIGNAL(OVERFLOW, 1) > ... > END SUBROUTINE B > END MODULE LIBRARY > > SUBROUTINE A > USE LIBRARY > ENABLE > CALL B > HANDLE (OVERFLOW) > ... > END ENABLE > END SUBROUTINE A > > This illustrates the use of a library module that may signal the > condition OVERFLOW. The signal statement causes a transfer to the > handler in the calling subroutine A. > > This also illustrates the effect of an intrinsic condition that is not > enabled. An overflow in Y*Z(I) would cause OVERFLOW to signal and > hence a > >COMMENT: change 'would' to 'may'. It is processor dependent whether the overflow > >COMMENT: signals outside of an enable block I agree. > transfer to the handler in the calling subroutine A. An out-of-range > subscript value I might or might not signal BOUND_ERROR, but it would > not be handled by subroutine A. > > Example 8: > > ENABLE, IMMEDIATE (OVERFLOW) > A = B*C > WHERE(RAINING) > X(:) = X(:)*A > ELSEWHERE > Y(:) = Y(:)*A > END WHERE > HANDLE > ..... > END ENABLE > > This illustrates the use of IMMEDIATE. The enable construct is equivalent to > > ENABLE (OVERFLOW) > A = B*C > ENABLE > END ENABLE > WHERE(RAINING) > X(:) = X(:)*A > ELSEWHERE > Y(:) = Y(:)*A > END WHERE > ENABLE > END ENABLE > HANDLE > ..... > END ENABLE > > Note that the statements of a WHERE construct are not tested separately. > > Example 9: > > SUBROUTINE LONG > REAL, ALLOCATABLE A(:), B(:,:) > >COMMENT: Add '::' to the above line to make it > >COMMENT: REAL, ALLOCATABLE :: A(:), B(:,:) Whoops! > : ! Other specifications > ENABLE > : > ! Lots of code, including many procedure calls > : > HANDLE (ALL_CONDITIONS) > ! Fix-up, including deallocation of any allocated arrays > IF(ALLOCATED(A)) DEALLOCATE (A) > IF(ALLOCATED(B)) DEALLOCATE (B) > : > END ENABLE > END SUBROUTINE LONG > > This illustrates the use of a handle statement with additional conditions. > Here the enable block enables no conditions because fast execution is desired, > but if anything goes wrong (for example, in one of the procedure invoked), > >COMMENT: change 'procedure' to 'procedures' - typo I agree. > > <<15. CONDITIONS>> > > In this section, the conditions supported by the standard and a statement for > >COMMENT: Change 'conditions supported' to 'conditions and corresponding condition > >COMMENT: names supported' > >COMMENT: The changes refer to condition names and we want to make it clear that > >COMMENT: we are defining a set of condition names as well as a set of conditions. I do not think that this change is necessary.