From gls@Think.COM Tue May 31 08:31:04 1994
Received: from Mail.Think.COM by dkuug.dk with SMTP id AA29610
  (5.65c8/IDA-1.4.4j for <sc22wg5@dkuug.dk>); Tue, 31 May 1994 18:32:04 +0200
Received: from [131.239.147.28] by mail.think.com; Tue, 31 May 94 12:31:08 -0400
From: Guy Steele <gls@Think.COM>
Received: by galileo.think.com (4.1/Think-1.2)
	id AA26747; Tue, 31 May 94 12:31:04 EDT
Date: Tue, 31 May 94 12:31:04 EDT
Message-Id: <9405311631.AA26747@galileo.think.com>
To: jkr@letterbox.rl.ac.uk
Cc: gls@Think.COM, sc22wg5@dkuug.dk
Subject: Condition enable proposal
X-Charset: ASCII
X-Char-Esc: 29


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 <scalar-int-expr> is zero; so the blanket
remark added by the edit ought to be qualified.

[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.

[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).

[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

--Yours,
  Guy Steele