From J.L.Schonfelder@liverpool.ac.uk Fri May 27 17:02:23 1994 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA07457 (5.65c8/IDA-1.4.4j for ); Fri, 27 May 1994 17:03:38 +0200 Received: from 138.253.31.200 by mailhub.liverpool.ac.uk with SMTP (PP) id <18948-0@mailhub.liverpool.ac.uk>; Fri, 27 May 1994 16:02:24 +0100 From: "Dr.J.L.Schonfelder" Message-Id: <9405271502.AA03682@uxb.liv.ac.uk> Subject: exception handling (fwd) To: SC22WG5@dkuug.dk (SC22/WG5 members) Date: Fri, 27 May 1994 16:02:23 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 8991 X-Charset: ASCII X-Char-Esc: 29 This is Mike's proposal. Although I think there are some details that need sorting this is the basis of a solution to what I believe is a total show stopper for the existing exception handling proposal. Prof L.M. Delves wrote > From delves@liverpool.ac.uk Fri May 27 13:48:45 1994 > From: "Prof L.M. Delves" > Message-Id: <9405271248.AA22272@uxd.liv.ac.uk> > Subject: exception handling > To: J.L.Schonfelder@liverpool.ac.uk (Lawrie Schonfelder) > Date: Fri, 27 May 1994 13:48:28 +0100 (BST) > Cc: peterc@algol.aleph1.co.uk (peter craven), > orthog@aleph-one-ltd.co.uk (Dave Lloyd Oxford), > daveo@liverpool.ac.uk (dave orange) > X-Mailer: ELM [version 2.4 PL23] > Mime-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > Content-Length: 7607 > > Lawrie (et al) > > The attached note is in response to JKR proposal, and has been triggered by JLS > comments. > > I would apprciate comments, suggestions, corrections of misunderstandings > etc, ASAP. I intend to send a corected version to UKFORTRAN and > individually to JKR. Help gratefully received. > > Mike D > _____________________________________________________________________ > Problems with the JKR May 94 CONDITION Handling proposal > > Preamble > > This proposal provides much needed functionality. But in its current > state, I believe it has defects which make it unacceptable. These > defects can be removed with only minor changes to the proposal. These > changes do not make life more difficult for implementors. I believe they > make life simpler for users even of simple facets of the facility. They > remove problems associated with namespace cluttering and unlimited > global visibility. They also remove the current irregularity in the > proposed syntax. > > I also propose an additional construct, the SELECT CONDITION construct, > which makes life simpler when handling conditions. This proposal is > additional to the primary one, and should be considered separately. > > Problems with JKR proposal > > a) Functionality > > Reprise: > All conditions, whether intrinsic or user-defined, are global. Hence, a > condition mentioned (they are not declared) in any subroutine, function, > or module (even in an internal procedure) are visible throughout the > program. > > Problem 1 > > The consequence of this is, as Lawrie Schonfelder has pointed out, a > cluttering of the namespace which has been (rightly) heavily resisted > with other constructs: for recent example, parametrised data types. > There are three obvious consequences for the user: > > 1) Conditions which he names, may be raised in routines whose content > he/she knows nothing of, leading to opaque behaviour of the programme. > > 2) Conditions with unexpected names may propogate back to the main > program unhandled and unhandleable because this knows nothinmg of their > existence. > > 3) It is not possible to be sure, without global analysis of the source > code, that the raising of a named user-defined condition relates to the > part of the code for which the condition was defined: there might be a > name clash with a condition meaning something totally different. > > In all cases it is no defence to say that the programmer should have > known of the existence of the conditions. If I replace one library > subroutine call by a call to another "improved" routine, I expect no > side effects. Global Conditions provide global side effects, with no way > of making them local. This is an unacceptably retrograde step for > Fortran to take. > > JKR recognises the existence of these problems by commenting that a > later extension might enable conditions to be local to a module, and to > be renamed via USE. That would give users a way round the problkem, > while leaving the dangerous features in existence. It is essential to > remove the problem before standardising it, not after. > > Problem 2 > > There is no mechanism for getting a called procedure to handle problems > via a user-defined condition. In a call to a procedure within an ENABLE > block, conditions may propagate back but only those known directly to > the procedure can be utilised. Users of versions of Basic with no > procedure parameters will know how awkward this is. > > Problem 3 > > In a main program, a potentially unbounded number of conditions may be > raised (all which ocurred at lower levels and were not handled, or were > re-raised). Handling these cannot be manageable over a large project: > it is not possible to write a handler which is secure against changes in > lower level routines. > > Problem 4 > > The concept of a CONDITION seems not to be precise. The following are > listed as CONDITIONS: > > DEFAULT, IO, FLOATING, INTEGER, ALL > > but each is said to be equivalenty to listing a set of named conditions > (and for DEFAULT, also any user-defined conditions). But these can only > be used as arguments to SIGNAL with second parameter 0 (ie, to switch > them off), or to switch on handling in an ENABLE block. It is convenient > to be able to refer to subsets of conditions via a single name, but > pointless and unnecessary to confuse a subset with an element of it. > Moreover, the limitations on their use is such that they give nmo > assistance with Problem 3. > > A Modification to the Proposal > > It is straightforward to remove all of these problems: > > 1) The new intrinsic type CONDITION is introduced. CONDITION variables > when declared have the implied value "quiet". They may take a finite > (implementation-dependent) set of discrete values. Assignment is not > predefined. No operations on CONDITIONs are predefined. > > The scope of CONDITION variables is determined by where they are > declared: no new rules are required. CONDITION variables declared in a > Module may be made available, and if wished renamed, via USE. > > 2) The implicit declaration > > CONDITION:: default > > is made in every program unit and is global to the program. > > 3) ENABLE(scalar or rank 1 array of CONDITION) is available as in JKR > > 4) So is HANDLE, SIGNAL, RESIGNAL, CONDITION_INQUIRE(condition, integer) > > The specification for SIGNAL is > SIGNAL(COND, VAL) > INTEGER, OPTIONAL::VAL > CONDITION, OPTIONAL::COND CONDITION,DIMENSION(:), OPTIONAL::COND > > If COND is absent the only valid value for VAL is 0. > > 5) CONDITION_INQUIRE(char_array) is deleted: not needed. > > 6) The flow of control is as with JKR. But if an unhandled (ie, > non-quiet) condition with local scope exists when a RETURN is required, > its value is assigned to the condition DEFAULT. If more than one such > condition exists, or if DEFAULT is already non-quiet, it is not defined > which value propagates; but the value is guaranteed to be non-quiet. > > 7) (it is suggested that - this proposal is to be viewed separately from > the rest since it adds convenience rather than fixing a problem) the > following SELECT construct be added: > > SELECT CASE (CONDITION) > CASE(condition or list of conditions) > : > CASE(condition or list of conditions) > : > [CASE DEFAULT] > : > END CASE > > The semantics of this construct are as follows: > > The CASE legs are scanned sequentially. If any listed conditions in the > current leg are raised, they are lowered on entry to the leg and the > body of the leg obeyed. The statement > > RESELECT > > if obeyed, will restore the values of the listed conditions. On > completion of the body of the leg, the END CASE statement is obeyed. > > If no named conditions are raised, the CASE DEFAULT leg, if present, is > scanned. If any conditions are active, it is entered. > > End of optional construct > > 8) Further facilities are made available through the intrinsic module > CONDITIONS. If the statement > > USE CONDITIONS > > is present, then: > > 8.1) The set of CONDITIONS ALLOCATION_ERROR....INTRINSIC are predefined > > 8.2) The predefined arrays: > CONDITION, DIMENSION(:):: & > IO = (/all i/o conditions/), & > INTEGER = (/integer conditions/), & > FLOATING = (/fp conditions/), & > ALL = (/all predefined conditions but not user conditions/) > are implicitly declared. > > Note: This module could also include SIGNAL and CONDITION_INQUIRE if > these were to be provided as subroutines rather than statements. The > module is introduced for neatness; it also allows implementations to > claim standard conformance without catering for the full range of > separate predefined conditions. > > > > > > -- Dr.J.L.Schonfelder Director, Computing Services Dept. University of Liverpool, UK Phone: +44(51)794 3716 FAX : +44(51)794 3759 email: jls@liv.ac.uk