From LJM@SLACVM.BITNET Thu Aug 25 01:57:00 1994 Received: from vm.uni-c.dk by dkuug.dk with SMTP id AA15968 (5.65c8/IDA-1.4.4j for ); Thu, 25 Aug 1994 21:05:49 +0200 Message-Id: <199408251905.AA15968@dkuug.dk> Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R2) with BSMTP id 2429; Thu, 25 Aug 94 21:05:40 DNT Received: from SLACVM.SLAC.STANFORD.EDU by vm.uni-c.dk (Mailer R2.07) with BSMTP id 9670; Thu, 25 Aug 94 21:05:39 DNT Received: by SLACVM (Mailer R2.08 R208004) id 9500; Thu, 25 Aug 94 12:04:40 PST Date: Thu, 25 Aug 1994 09:57 -0800 (PST) From: "Len Moss" To: "SC22/WG5 Mailing List" Subject: Re: (SC22WG5.622) Len Moss letter ballot on enable X-Charset: ASCII X-Char-Esc: 29 In-Reply-To: jkr@letterbox.rl.ac.uk -- 08/25/94 09:03 > >Thank you, Len, for your careful reading of the enable proposal. We missed >you in Edinburgh. Thanks, John -- I'm sorry I missed it. > >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. John and I have long disagreed on this. I think the proposal is far from simple, even with the cuts that have been made. > >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. We could also just do it right 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. I agree user-named conditions are too ambitious for 95, but then I feel the same way about the entire proposal. > >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. It seems to me that the statements we used to call CHECK and RESIGNAL really do exactly the same thing and therefore should be a single statement. The latest proposal apparently agrees, and suggests that statement should be spelled, "ENABLE; END ENABLE" -- I'm merely suggesting an alternative spelling. > >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. I thought I was merely correcting an example to conform to your own specification. The third (non-footnote) paragraph of section 8.1.5.2 of the proposal states, 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. A where construct is, indeed, an executable construct, but so is each assignment statement within the where construct. I understand the above words to apply recursively to all constructs nested within other constructs, and that was my intent when I originally suggested some functionality like the IMMEDIATE clause. > > >Here are my detailed responses. AEstuff omittedAA > >> 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. Sorry, I don't understand the IEEE issues well enough to suggest words -- perhaps Keith could come up with something. > >> 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: >> AEhandful of examples omittedAA >Yes, we need to make edits in these places. And in many other places as well! Those half dozen examples are not the result of an exhaustive search of the whole text but of just a few quick checks. My point is that adding exception handling forces us to take a whole new approach to writing prohibitions. This is one of the major reasons I believe exception handling will cause the schedule to slip. AEstuff omittedAA >> >AEFootnote: Although multitasking is not part of Fortran 90, the interaction >o > f >> >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.AA >> >> 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,"? That would definitely help. AEstuff omittedAA > >> >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 >n > o >> >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. If my interpretation above about the effect of the IMMEDIATE clause on nested constructs is accepted, I'd prefer that the two parts of IF and WHERE statements be handled (for the purposes of the IMMEDIATE clause) as two separate statements, just as they are for the purposes of function side effects (7.1.7). This is consistent with a mental model in which the IF and WHERE statements are simply degenerate cases of the corresponding constructs. AEstuff omittedAA > >> 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. One obvious point would be the mnemonic value of defining a parameter named QUIET to be used to turn conditions off. In any case, I thought one of the goals of the "language evolution" proposal was to get rid of unnecessary restrictions in order to make the language more regular. Requiring a literal 0 is akin to the strange requirements on the operands of STOP and PAUSE, recently debated yet again on the interpretations list. AEstuff omittedAA >> >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 Yes, SYSTEM_ERROR is better than INEXACT for this example, but _only_ because it's less likely to actually occur in this particular problem, not because it's any more appropriate for the use to which it's being coerced. My point was that, since there is no intrinsic condition that really signifies "timeout", and no way to define such a condition, one is forced to misuse some other intrinsic condition for this purpose. There will be a significant long-term cost to the lack of user-defined condition names in terms of code libraries littered with inappropriate uses of intrinsic conditions. These will be difficult to maintain and will also make it difficult for implementers to make even minor changes in condition signalling. I'd suggest cutting this example entirely. If the proposal does not support user-defined exceptions, we should not suggest ways of perverting it to do so. AEstuff omittedAA >> >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. And, in F95 presumably, nested WHEREs and FORALLs. This is part of the integration problem -- for the IMMEDIATE clause to be useful, the _effect_ has to be to check for signalling conditions after every lowest-level executable construct. If you choose to describe this in terms of equivalent explicit code, then you have to make sure that equivalent code is legal. I don't think there would be a serious problem with permitting a CHECK or SIGNAL * statement in WHERE blocks, but permitting an empty enable block opens up a big can of worms. You then have to go back and review a number of previous decisions (whether to add an IMMEDIATE clause at all, what it's effect should be if you do add it, how you describe it, whether to drop the CHECK statement, etc.) and make some adjustments. This is an iterative process, and you don't have much time (2 meetings!) for the iterations to converge and the text to get written. > >> >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: Much better. > >> >....................................................................... >> > >> >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=. Yes I know, but this should be spelled out here as well. AEadditional instances omittedAA > >> >AEFootnote: An array size 20 will always be adequate to return the names of >al > l >> >the conditions defined by the standard. If the final element of the >characte > r >> >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.AA >> >> 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? In that case it's better to say nothing, or to suggest that the user look at the processors documentation to decide how big to make the array. By the way, I read the following sentence, If there are more signaling conditions than the size of the array, all elements are defined with condition names and which are chosen is processor dependent. To meant that if the array was too small to hold all signalling conditions, then there was no requirement to put the standard ones first. Was that the intent? If so, why? It would seem that a guarantee that the standard conditions would always come first would pretty much render this whole question moot. If that was not the intent of the above sentence, then what _does_ it mean? AEstuff omittedAA -- Leonard J. Moss o/ My views don't necessarily Stanford Linear Accelerator Center o/ reflect those of SLAC, MS 97; P.O. Box 4349; Stanford, CA 94309 o/ Stanford or the DOE