From J.L.Schonfelder@liverpool.ac.uk Thu Sep 1 06:38:29 1994 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA20064 (5.65c8/IDA-1.4.4j for ); Thu, 1 Sep 1994 14:35:53 +0200 Received: from pop.liv.ac.uk by mail.liv.ac.uk with SMTP (PP); Thu, 1 Sep 1994 13:35:25 +0100 Date: Thu, 1 Sep 1994 13:38:29 PDT From: Lawrie Schonfelder Subject: Letter Ballot on ENABLE proposal To: SC22WG5@dkuug.dk Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII X-Charset: ASCII X-Char-Esc: 29 Like Len Moss I have to vote NO on this proposal as acceptable for inclusion in Fortran 95. I would in fact endorse most of Len's comments and I will add a few of my own. 1. Schedule. I do not believe the proposal as defined in 94-258r4 to be acceptable and do not believe it possible to correct it in time to be included in F95 given the current schedule. However, my reaction to this is different from Len's (I think). I believe a number of key additions to Fortran are critical to Fortran's continued importance as a major general purpose language for scientific and engineering application. Exception Handling is one of these, as is parameterised datatypes IMO. I think it essential that both these functionalities are available properly in F9x. If it takes a little longer to get these into the langauge then the schedule should be modified to accomplish this. Schedule dictating content I now believe to be an unwise decision. 2. I do not think the cutdown proposal removing user defined conditions is acceptable. The "simplifications" it produces are neither real simplifications nor is the functionality left adequate. The refusal to properly deal with the scoping questions related to conditions user or intrinsic leads to far too much ad hoc irregualar language design to be acceptable. Not to have user defined conditions in the context of a semantically extensible language like Fortran 90/95 simple adds to the general irregularity which will cripple Fortran relative to C++. The user can extend the set of types, procedures (functions and subroutines), and operators. To add conditions without adding the facility for extending the set of conditions from the intrinsic is simply an unacceptable irregularity and an unacceptable constraint on the functionality. The problems involved in adding this functionality are central to and fundamental for a well designed simple regular language extension. Ducking the issues raised by this requirement produces complication because it introduces irregularity. This is not KISS (John and I continue to disagree on what KISS implies even though in principle we agree that KISS is a good motherhood approach to extension). 3. I agree with Len that disallowing transfer of control out of ENABLE/HANDLE blocks is unacceptable. This is another ad hoc irregularity. No other Fortran block has this restriction. The condition handling extension should be properly designed to preserve this general feature of block control constructs. The consequences of transfer out if used might be reduced performance but the choice should be left to the user and the efffect properly defined. 4. I think spelling RESIGNAL as ENABLE;ENDENABLE seriously unfriendly. I cant help feeling that the coincidence that the empty block has the effect of a resignal is a further sign of a possible design problem. 5. Conditions should not be defined to have default integer values as such. The standard should merely define that there must exist a mapping between condition values and the default integers. This mapping should be constrained so that "quiet" conditions map to zero, processor initiated signals map to positive integers and user initiated signals map to negative. The internal representation and hence actual value of a condition should not be defined by the standard but left up to the processor. 6. The imprecision of where conditions signal and where they dont is unacceptable. To say that for some conditions you have to say ENABLE (condition) to cause them to signal and others that signal whether enabled or not. If a condition is not enabled it should be exactly F90 rules, entirely processor dependent. All currently unenabled conditions included on an ENABLE statement should be set to quiet on entry to an enable block, rather than as currently defined where such a condition would cause a transfer of control rather than entry to the enable block. I think this is related to the refusal to properly handle the scoping of conditions and therefore the domain of program where this extension might effect the execution of the program. A program and program unit which does not include any condition handling (a F90 program for instance should behave in exactly the same way as it did under F90). Adding an ENABLE block to such a program should only have effects on the code included in the enable block. By making intrinsic conditions global rather than allowing the user any control over the scope of the conditions themselves means that it is only the ENABLE blocking that can control the domain of program code that is effected. The overall concern is that the effect on program execution of the inclusion of condition handling statements should be confined to a well defined domain of program code, namely, the code where the statements are included. 7. The inclusion of conditions on HANDLE statements appears a little strange. The concern may be related to those of the above topic, but it appears counter intuitive that a Handler could suddenly appear for a condition not enabled by its corresponding ENABLE. It appears to allow ENABLE(cond1) ... ENABLE(cond2) ... HANDLE(cond1) ... ENDENABLE HANDLE ... ENDENABLE This sort of transfer pattern looks strange. It might be desirable to include condition names on Handlers and to allow multiple handle blocks, cf. ELSEIF blocks. ENABLE(cond1,cond2,...) .... HANDLE(cond1) ! handler for condition 1 only HANDLE(cond2) ! handler for cond2 only HANDLE ! handler for any other conditions signalling ENDENABLE 8. I agree with Len that exception handling requires a much more systematic way of handling the description of prohibitions in the language. With exception handling it must be made clear in what contexts the processor is permitted to do its own thing and where it is required to raise a signal. This must be done carefully to preserve backwards compatibility. This does not appear to have been achieved nor is it clear that as currently designed it is possible in a simple regular way to achieve it. Finally, although I am voting NO on the current proposal I wish to stress that I believe the time should be taken to produce a complete condition handling extension adding properly scoped user defined conditions and providing proper control over the scope of intrinsically defined conditions. Until this is done I do not believe an acceptable extension can be designed and F9x needs such an extension. -- 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