From J.L.Schonfelder@liverpool.ac.uk Sat Jul 9 02:30:21 1994 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA29536 (5.65c8/IDA-1.4.4j for ); Sat, 9 Jul 1994 10:31:46 +0200 Received: from liverpool.ac.uk by mailhub.liverpool.ac.uk with SMTP (PP) id <21194-0@mailhub.liverpool.ac.uk>; Sat, 9 Jul 1994 09:31:23 +0100 Date: Sat, 9 Jul 1994 09:30:21 PDT From: Lawrie Schonfelder Subject: Exception handling To: SC22/WG5 members Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Charset: ASCII X-Char-Esc: 29 This is positively the last mail from me before the Edinb. meeting!! I forgot to send it yesterday and am doing the last minute clean up. The paper that follows is incomplete as I did not have time to do all the additional edits to John's paper but I think there is enough description to indicate the technical direction being proposed to fix the problems I see in the current proposal. ---------------------------------------------------------------------- To: X3J3 and WG5 (7 July 1994) From: Lawrie Schonfelder References: X3J3/94-147r3 "JKR's ENABLE Proposal e-mail discussion notes by JLS and Mike Delves Condition Handling 1 Introduction This is an attempt to take the suggestions made by Mike Delves and to combine it with the basic structure of the proposal by John Reid in X3J3/94-147r3. The aim of this is to solve the serious problems with the proposal as it stands in the latter document. The problems with the existing proposal results from the definition of conditions as global. This seriously clutters the global namespace. Even though as defined condition names are in a separate global class from all other global names, they are still global and this results in an intractable problem. As written we allow the same condition names to apply to more than one independent condition entity in the same program. These could possibly be defined in entirely separate libraries of procedures written by totally independent authors who happen just to choose the same name for a condition. In this case we have allowed the possibility of legal but ambiguous or erroneous programs. In the existing proposal conditions have global names and their signalling if not handled propagates back up the call chain searching for a handler. As a result a routine in a higher position in the call chain cannot be confident that the condition it thought it was handling is the one it was designed to deal with. It is always possible for a routine lower in the call chain about which the upper level routine knows nothing to have signalled using the same condition name and for this to have propagated. The higher level handler is now quite possibly handling the wrong condition with highly unpredictable results. This behaviour violates almost every principle of good programming practice. If I call a procedure A to perform some task, I should not be required to know anything about the body of A, only A's interface. It is entirely unacceptable that I should have to be aware of not only of conditions that A might wish to signal back to me but every condition that might be signalled from any routine called in any chain originating from the routine A. It is clear that the functionality of condition handling is one that is desperately needed. I am therefore trying to suggest ways in which the problems might be resolved. To this end the following is a development of the suggestion made by Mike Delves to deal with these same issues. An additional difficulty is also that it is undesirable for the standard to require that condition values be represented by values of type integer. It is entirely possible for a processor to prefer to store condition values in some other internal form which may be more optimal on the specific hardware; packed bits is some form of status word for instance would be a possibility. The alternative discussed below attempts to leave the processor maximum freedom to handle the precise internal representation of a condition value. The only requirement that will be imposed is that there must exist a mapping between this internal representation and a subset of the integers. { I have not had time to complete this paper as I would have wished and it is therefore left incomplete, but I hope it is sufficient to indicate a possible resolution of what otherwise I fear are problems which render the proposal unacceptable. } 2 Outline Technical Description The proposal is to make relatively few changes to John's current proposal. The major thrust of the change is to make conditions declarable with a defined local scope. This removes the global name problems at a stroke. The type indicator should be spelt CONDITION. The processor will be required to store by some unspecified mechanism a set of discrete values for conditions. It must, however, be possible to map condition values onto a subset of the integers. This subset must at least contain zero which maps to the "quiet condition", and at least one non-zero value to act as a nonquiet signal. A range of positive values and a similar range of negative values might also be represented. These nonzero values map to nonquiet conditions. But other than these mapping requirements no storage forms or constraints are placed on the mechanisms that processors must employ to signal or represent condition values. This would allow a system that recorded conditions packed into a status word to use this mechanism without having to resort to integers to record the conditions except where the program requires such a mapping. A condition would have to be declared before it could be enabled and hence monitored within an enable block. An example of a condition declaration would be CONDITION :: TOO_MANY_ITERATIONS All condition variables are created in a quiet state, they would map to a corresponding integer value of zero. That is, the condition type is a type with a defined initial state. However, condition objects are not like data objects in that the only contexts in which they can occur are in the specific condition handling statements. It is not proposed that they be permitted in assignment statements or that operations be defined for values of type condition, or even that conditions be passed as arguments or included in storage association contexts. They would however, be accessed via use and host association. The statements in which conditions may appear are more or less as in 94-147r3. The major difference is that now a condition can only signal up the call chain provided the condition name remains in scope. An essential feature of this proposal is that if a named condition ceases to exist, because the procedure it is declared in returns or the module it is declared in becomes inactive, and the condition is signalling nonquiet (it has not been handled) the program should terminate with an implied STOP that issues a message identifying the condition, the integer map of its value and the program unit. That is the program terminates as if it executed a stop statement essentially of the form STOP condition-name = INT(condition-name) in program-unit-name If more than one condition is signalling the warning message must be repeated for each such condition. The set of intrinsic conditions as defined by 94-147r3 will remain but will be considered as being declared in an intrinsic module called perhaps, INTRINSIC_CONDITIONS. In the absence of a USE statement naming this module, the intrinsic conditions cannot be enabled and the behaviour of the program if one of the intrinsic conditions is caused, is system determined as now. { This has the added advantage as no change in existing program behaviour is caused by the extension unless the user explicitly asks for the extended condition handling as per this extension. A further possible complication with the existing proposal. } There are additional questions that need to be dealt with. What happens if a nonquiet condition is signalled with a handle block part of a block which enabled the condition. I would suggest that this should cause a further imprecise interrupt of the handler and processing should continue with the first statement following the ENDENABLE. A related question is where in the handle block does a nonquiet enabled condition get set to quiet. Again I would suggest that this is when the ENDENABLE is executed, viz. when the normal execution sequence of the handler completes. Any transfer out of a handler should leave all conditions signalling their state at the point of transfer. { I do not believe these changes are difficult to implement, nor do they require very much additional editorial work to include in F96. } --------------------------------------------------------------------- One final observation on the future of Fortran which I would like to make before finishing packing and setting off to catch a plane is: The most significant thing required to make Fortran a real competitor in the general scientific applications building area for c/c++ is the provision of Fortran interfaces to the Windows and X-windows environments. At the moment the single most effective pressure prompting my users to switch to c/c++ (or visual basic) is the capability that these have of creating applications which operate as windows applications in either the MS-windows environment or the x-windows one. (I suspect there may be in some places pressure for Mac interfacing but as we are a non-mac site we do not feel this). A dramatic fillip would be given to Fortran is a module interface could be produced that would provide a fortran9x interface to the MS-win and x-win DLLs. Without such interfacing I fear Fortran, regardless of the adding of essential extended functionality (such as those we are now discussing), will fall into an increasingly narrow niche market of high perforamnce number crunching. A position from which I think decline into obscurity is inevitable. Whether WG5 can do anything about defining and or standardising such interfacing is a significant question but someone needs to do it and I dont know of any body else likely to do so. Have a good meeting! See you all next time. Regards Lawrie -- Dr.J.L.Schonfelder Director, Computing Services Dept. The University of Liverpool, UK e-mail J.L.Schonfelder@liv.ac.uk phone: +44(51)794-3716 fax: +44(51)794-3759