From J.Reid@letterbox.rl.ac.uk Thu Jun 16 15:17:33 1994 Received: from ib.rl.ac.uk by dkuug.dk with SMTP id AA27297 (5.65c8/IDA-1.4.4j for ); Thu, 16 Jun 1994 15:17:33 +0200 Received: from letterbox.rl.ac.uk by ib.rl.ac.uk (IBM VM SMTP V2R1) with TCP; Thu, 16 Jun 94 14:17:00 BST Received: from jkr.cc.rl.ac.uk by letterbox.rl.ac.uk with SMTP (PP) id ; Thu, 16 Jun 1994 14:13:27 +0100 Received: by jkr.cc.rl.ac.uk (4.1/SMI-4.1) id AA06257; Thu, 16 Jun 94 14:15:16 BST Date: Thu, 16 Jun 94 14:15:16 BST From: jkr@letterbox.rl.ac.uk (John Reid) Message-Id: <9406161315.AA06257@jkr.cc.rl.ac.uk> To: gls@Think.COM Subject: Re: Condition enable proposal Cc: SC22WG5@dkuug.dk X-Charset: ASCII X-Char-Esc: 29 Thank you for your careful reading of the enable proposal. I am very sorry to be slow in commenting. I was away in the week that it came and I have had trouble catching up with other urgent matters. > > I have read the Eanble proposal dated 7 May 1994 and have > a few questions and comments. > > [1] The edit at 12/53+, which adds the statement: > (4) Execution of a signal or resignal statement (8.1.5.4) > changes the execution sequence. > If I understand correctly, a signal statement does *not* change the > execution sequence if the is zero; so the blanket > remark added by the edit ought to be qualified. Agreed. I will modify the proposal. > > [2] Is there any operational difference between the RESIGNAL > statement and the statement sequence > ENABLE (ALL) > END ENABLE > ? If so, I would like to understand the difference. > If not, then this equivalence might be worth noting. Agreed. I will add a footnote and make the wording identical in the two places. > > [3] In Example 5, ought the lines > ! The following code is executed every iteration > through > END IF > have a DO loop of some kind around them? It would be clearer > to show such a loop than to have the colons (apparently intended > as ellipses). I think it is OK as is, but would be happy to make a change if others want it. > > [4] As I think examples 2 and 6 attest, many if not most uses > of CONDITION_INQUIRE will be immediately followed by a statement > "IF (K /= 0) ..." and every such use increases the indentation level. > While I am always reluctant to propose additional syntax for a language, > here it seems justified: allow "IF CONDITION ( condition-name-list )" > anywhere that "IF ( scalar-logical-expr )" may appear. The meaning of > IF CONDITION ( x, y, ..., z ) > is roughly > CONDITION_INQUIRE (x, x_temp) > CONDITION_INQUIRE (y, y_temp) > ... > CONDITION_INQUIRE (z, z_temp) > IF (x_temp /= 0 .OR. y_temp/=0 .OR. ... .OR. z_temp/=0) > I think you will find the reduction in textual complexity of > error-handling code worth the addition to the language. > The relevant portion of example 2: > > HANDLE > CONDITION_INQUIRE(END_OF_FILE,K) > IF (K/=0) THEN > WRITE (*, *) 'Unexpected END-OF-FILE when reading ', & > 'the real data for a finite element' > ELSE > CONDITION_INQUIRE(IO_ERROR,K) > IF (K /= 0) THEN > WRITE (*, *) 'I/O error when reading ', & > 'the real data for a finite element' > END IF > END IF > STOP > END ENABLE IO_CHECK > > becomes rather shorter and easier to follow: > > HANDLE > IF CONDITION (END_OF_FILE) THEN > WRITE (*, *) 'Unexpected END-OF-FILE when reading ', & > 'the real data for a finite element' > ELSE IF CONDITION (IO_ERROR) THEN > WRITE (*, *) 'I/O error when reading ', & > 'the real data for a finite element' > END IF > STOP > END ENABLE IO_CHECK > I am afraid I am opposed to this change. For the sake of KISS, I am trying to avoid interactions with other parts of the language as far as possible. It is pleasing that most of the proposed edits are in new self-contained sub-sections. This would involve a change to the IF construct. > > Date: Fri, 3 Jun 1994 10:45:45 -0700 > From: meissner@lynx.cs.usfca.edu (Loren P. Meissner) > > > Instead of IF Condition (...) then > wouldn't > IF (CONDITION (...)) then > work just as well, where CONDITION is an intrinsic > procedure with various arguments > > Could be. I thought of that, but assumed that for some > reason the proposer was trying to avoid the use of functions > whose values change "under the table". (There is ample > precedent for this in Fortran; else why not have a function > RANDOM_NUMBER instead of requiring use of a subroutine?) > Moreover, the proposer seemed to avoid even the use of > a subroutine, instead preferring the special syntax > CONDITION_INQUIRE; I guessed that there might be some > efficiency concern, and in any case tried to propose > a solution in keeping with the overall tenor of what > was already there in the proposal. Anyway, now the issues > are more explicitly out on the table, which is good. > The reason is for scoping, as well as efficiency. Condition names can appear on in ENABLE, SIGNAL, and CONDITION_INQUIRE statements. There is no need for quotes and no possibility of non-constant values. Best wishes, John Reid.