From J.Reid@letterbox.rl.ac.uk Thu Aug 25 16:49:31 1994 Received: from ib.rl.ac.uk by dkuug.dk with SMTP id AA09884 (5.65c8/IDA-1.4.4j for ); Thu, 25 Aug 1994 16:49:31 +0200 Received: from letterbox.rl.ac.uk by ib.rl.ac.uk (IBM VM SMTP V2R1) with TCP; Thu, 25 Aug 94 15:49:15 BST Received: from jkr.cc.rl.ac.uk by letterbox.rl.ac.uk with SMTP (PP) id ; Thu, 25 Aug 1994 15:46:31 +0100 Received: by jkr.cc.rl.ac.uk (4.1/SMI-4.1) id AA04158; Thu, 25 Aug 94 15:48:45 BST Date: Thu, 25 Aug 94 15:48:45 BST From: jkr@letterbox.rl.ac.uk (John Reid) Message-Id: <9408251448.AA04158@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Len Moss letter ballot on enable X-Charset: ASCII X-Char-Esc: 29 Thank you, Len, for your careful reading of the enable proposal. We missed you in Edinburgh. I have prepared detailed responses to Len's comments, which follow. His major points are: 1. It cannot be done in time. I have to differ with Len here. The proposal has been carefully constructed to be a simple one. The removal of user names (which Len does not like) makes it simpler than it was prior to Edinburgh. 2. He wants to allow transfer of control out of enable blocks. We did hesitate over this one in Edinburgh, ending by keeping what we had prior to the meeting (but with some additional edits). We have also hestitated about it at the Feb and May meetings. I do not see it as a big issue. As Len says, the wording about what is undefined would need to be altered if we allowed these transfers. What do other people think about this? One merit of the present rule is that it is restrictive and could be broadened in 2000. 3. He wants user-named conditions. This issue was extensively discussed by WG5 and a firm decision made. Having no user names and no catch-all USER condition allows user names with local scope to be added in 2000. To add them them in 95 would be too ambitious. 4. He prefers the explicit CHECK and RESIGNAL statements to the use of ENABLE; END ENABLE This is a decision that was made by WG5. It was felt to be inconsistent to have a RESIGNAL statement and not have a CHECK statement. 5. He wants IMMEDIATE to separate the statements within a where construct. It would be possible to define IMMEDIATE to do what he wants. We would have to say that where constructs are replaced by the equivalent set of where statements. I prefer to leave such an extension to 2000, or even to defer the whole of IMMEDIATE to 2000. Here are my detailed responses. > > I vote NO on the Enable proposal, 94-258r4. My principal reason for > voting NO is that I do not believe this proposal can be correctly > integrated into a complete standard within the time allotted for > producing Fortran 95. Even a "good faith" attempt to do so is, in > my opinion, likely to consume too much of the committee's resources > and result in a substantial delay for the remainder of the Fortran > 95 work. See 1 above. > In addition to this schedule concern, I have very serious objections > to the technical content of the proposal. > > The restriction against transfers of control out of enable > constructs is too onerous and would make the facility unusable for > the average user. Moreover, this restriction would encourage the > misuse of the facility in certain cases to simulate a transfer of > control. Here is a modified version of Example B from the proposal > illustrating the kinds of abuses I have in mind: > > ! Example B-prime: > ! This example is similar to Example B, but (mis)uses two > ! additional conditions, ALLOCATION_ERROR and DEALLOCATION_ERROR, > ! to simulate the effect of CYCLE and EXIT. It is assumed that > ! the fast algorithm does not make use of the ALLOCATE statement. > ENABLE (OVERFLOW) > ! First try a fast algorithm for inverting a matrix. > : ! Code that cannot signal overflow > ENABLE (DEALLOCATION_ERROR) ! Set up to simulate EXIT > DO K = 1, N > ENABLE (ALLOCATION_ERROR) ! Set up to simulate CYCLE > : > IF ... SIGNAL (ALLOCATION_ERROR,-1) ! Simulate CYCLE > : > IF ... SIGNAL (DEALLOCATION_ERROR,-1) ! Simulate Exit > : > HANDLE ! Receives control on simulated CYCLEs > END ENABLE ! for simulated CYCLEs > END DO > HANDLE ! Receive control on simulated EXITs > END ENABLE ! for simulated EXITs > ENABLE > : > END ENABLE > HANDLE > ! Alternative code which knows that K-1 steps have executed normally. > : > END ENABLE > > If necessary, the rules about which variables become undefined when a > condition is signalled will have to be broadened in the presence of > transfers of control (even conditional transfers) inside an enable > construct. See 2 above. > > The lack of user-defined conditions is also unacceptable. It will > inevitably lead to the misuse of intrinsic conditions. Furthermore, > I no longer think that previous solutions to this problem, namely, > a single catch-all USER condition or global scope for all condition > names is acceptable. User condition names should be declared and > should follow the same scoping rules as for variables. > See 3 above. > The interaction of this proposal with the automatic deallocation > proposal is not spelled out and appears to be tricky: the latter > eliminates the allocation status of "undefined", but this appears > to be what is required if an ALLOCATE statement occurs somewhere in > the innermost ENABLE block when a condition is signalled. No, the intention is that the allocation status be either currently allocated or not. The undefined status is abolished. If there is an allocation statement among those that may or may not have been executed in an enable block, the intrinsic ALLOCATED can be used to find out whether the array is currently allocated or not. > This proposal give no guidance to an IEEE implementer as to whether > an ENABLE statement is an appropriate vehicle to control whether > numeric exceptions signal or propagate. At first glance, it would > seem to be a good choice, but I suspect there are a variety of > pitfalls to such an approach. There should be some discussion of > this issue in a footnote. Some suggested wording would be appreciated. There is a footnote now near the start of 8.1.5. > In the past, we have always interpreted a program that violates an > absolute prohibition in the text as non-conforming and permitted the > processor to deal with such programs any way it sees fit; the > exception handling facility would limit the freedom of the processor > to deal with many violations of the existing rules, but the edits in > this proposal do not reflect this. Here are just a few examples of > conditions and conflicting absolute prohibitions: > > BOUND_ERROR > 64/31, "The value of a subscript in an array element must be > within the bounds for that dimension." > 65/33-34, "Each subscript [in a sequence of subscripts > by an array section] must be within the bounds for its > dimension unless the sequence is empty." > > SHAPE > 90/5, "For an intrinsic assignment statement, and > must conform in shape..." > > MANY_ONE > 89/31, "The [in an array assignment statement] must > not be a many-one array section." > > PRESENT > 179/31, "A dummy argument that is not optional must be > present." > > UNDEFINED > 61/4, "A reference is permitted only if the data object is > defined." Yes, we need to make edits in these places. > Adding a special statement to resignal conditions inside a handler > my be redundant with an empty ENABLE/END ENABLE block, but it is far > more intuitive. See my comments below regarding empty enable blocks > outside of handlers. See 4 above. > In a handler, is it possible to first set some conditions quiet, then > resignal any conditions that are still signalling? Yes. > If so, what happens > if a condition is raised _within_ such a handler -- does the set of > signalling conditions itself become imprecise? It is not more imprecise that anywhere else. The processor may or may not continue in execution after a condition is signaled. > Note that it is not > possible to avoid such imprecision by nesting additional enable blocks > since the first ENABLE encountered inside the handler causes the > resignal. See the footnote near the end of 8.1.5.1. > >If a condition is still signaling when the program stops, the processor must > >issue a warning on the default output unit. > > The warning should be required to include a list of all signalling > conditions at termination time and their associated integer values. I have no objection to making this change. > >[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.] > > I don't understand this -- does it mean that an enable statement > _inside_ a PURE procedure forces a merge of condition values across > all concurrently executing instances of the procedure? I suspect > not, but I don't see anything in the edits below that spells out > exactly what it does mean. It was not. A pure procedure on a processor may signal a condition and handle it locally without any reference to other processors. How about adding to the front of the last sentence: "If an enable construct contains statements that spawn tasks,"? > The statement at 95/18, "Execution of such a block [i.e., an empty > block] has no effect." needs at least a footnote distinguishing > _entry_ into an empty enable block, which can indeed have an effect, > from execution of the (null) block itself. I do not see the problem. What effect can "entry" cause? It does not occur unless all the conditions handled are quiet. > If the restriction against transfers of control out of an enable > construct is retained, section 8.1.1.2 [95/33-37], "Control flow in > blocks" needs to be rewritten. Well, some edits to the second sentence are needed, certainly. > >Any of the enable block that might signal one or more > >of the conditions in the immediate list on the enable statement is treated as > >if it were followed by an with an empty enable block and no > >handler. > > If a condition in the immediate list is signalled while evaluating the > part of an IF statement, must the transfer of > control occur before execution of the part of the IF > statement? No. > Enable constructs themselves must be properly nested; however, empty > enable blocks can be freely scattered amongst other types of blocks > to act as exception-handling barriers without requiring any special > nesting; for example, > > : > ENABLE;END ENABLE > DO ... > : > ENABLE; END ENABLE > IF...THEN > : > ENABLE; END ENABLE > ELSE > : > ENABLE; END ENABLE > END IF > : > ENABLE; END ENABLE > END DO > > This is fairly ugly and should be replaced with a single statement > that would have the same effect (and which could also be used to > resignal conditions within a handler -- see my comments above). > I suggest something like 'SIGNAL *'. It would not be difficult to reinstate the CHECK statement, but the WG5 decision is not to have either the CHECK or the SIGNAL statement. > Why must a literal 0 be used to set combination conditions quiet? A > symbolic constant (e.g., "QUIET") or even an initialization > expression with a value of zero would seem to work equally well and > be more regular. I see not point in the extra generality. 0 is the only permitted value. > >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 > > Modules themselves can't signal; "module" in the above line should > be changed to "module procedure". Agreed. > >Example 5: > > > This example illustrates my point about the need for user-defined > condition names. INEXACT is not really an appropriate condition > name for a time-out situation, and is a particularly poor choice > for this example, since there is a very real likelihood that the > function F could, on an IEEE machine, itself raise the INEXACT > condition. Yes, it would be better to use SYSTEM_ERROR in this example > >Example 7: > > > > > >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 > >transfer to the handler in the calling subroutine A. ... > > I thought whether or not such a transfer occurred was > processor-dependent. Yes, this needs an edit. > >Note that the statements of a WHERE construct are not tested separately. > > What?! The statements of a WHERE construct are executed in sequence so > they should be tested separately. The equivalent construct should be: > > ENABLE (OVERFLOW) > A = B*C > ENABLE > END ENABLE > WHERE(RAINING) > X(:) = X(:)*A > ENABLE > END ENABLE > ELSEWHERE > Y(:) = Y(:)*A > ENABLE > END ENABLE > END WHERE > ENABLE > END ENABLE > HANDLE > ..... > END ENABLE > > Moreover, if there were multiple assignments within one of the WHERE > blocks (at least, multiple assignments that could conceivably cause > an overflow), each such assignment should, in the equivalent > construct, be followed by an ENABLE/END ENABLE pair. The code you have constructed is not legal Fortran. Where constructs may contain only assignment statements. See 5 above. > >122/17-18. Replace sentence by > > If an error condition (9.4.3) occurs during execution of an input/output > > statement that lies in an enable block for the IO_ERROR condition or > > contains an ERR= specifier: > > Poor wording -- it sounds like the enable block contains an ERR= specifier. I do not think it parses with this interpretation, but how about transposing the clauses: If an error condition (9.4.3) occurs during execution of an input/output statement that contains an ERR= specifier or lies in an enable block for the IO_ERROR condition: > >....................................................................... > > > >122/25. After 'continues with' add 'the handle block or' > > This text does not spell out whether the ERR= statement or the handler > takes precedence when both are present. Yes, an edit is desirable. The definition of IO_ERROR makes it clear that the condition does not signal in a statement with an END=. > >122/34. After 'continues with' add 'the handle block or' > > This text does not spell out whether the END= statement or the handler > takes precedence when both are present. Again, an edit is desirable. > >123/6. After 'continues with' add 'the handle block or' > > This text does not spell out whether the EOR= statement or the handler > takes precedence when both are present. Again, an edit is desirable. > >[Footnote: An array size 20 will always be adequate to return the names of all > >the conditions defined by the standard. If the final element of the character > >array has the value blank, the names of all signaling conditions will have > >been returned. If it is not blank, the user may set the conditions named > >quiet with SIGNAL statements and call CONDITION_INQUIRE again.] > > How? The returned condition names are character values, but the > SIGNAL statement requires a in the BNF sense, not a character > value. One could write a big SELECT to handle the standard > intrinsic conditions, but there's no portable way to handle > conditions added by the implementation. Yes, we discussed this point in Edinburgh. The words have been chosen not to promise always to find all processor-defined conditions. We felt that this was a bit academic. Do we really expect that there are likely to be more than 20 processor-defined conditions? And even if there are, how often will more than 20 be signaling? > >INSUFFICIENT_STORAGE > >This indicates that the processor is unable to find sufficient storage to > >continue execution. It may occur prior to the execution of the first > >executable statement of a main program or procedure and it may occur during > >the execution of an executable statement. It need not signal if > >ALLOCATION_ERROR signals. It signals outside enable blocks. > > How does this interact with the automatic deallocation proposal? > Suppose this condition is signalled in routine A which does not have > a handler for it, and that substantial space is freed when control > is returned to A's caller, B. Assume B also has no handler for this > condition and that the processor simply continues execution in B, > including a number of operations that successfully allocate and free > memory. Is the INSUFFICIENT_STORAGE condition still signalling? Yes. Nothing has set it quiet and A has failed to execute as intended.