From J.Reid@letterbox.rl.ac.uk Thu Sep 1 18:07:52 1994 Received: from ib.rl.ac.uk by dkuug.dk with SMTP id AA25675 (5.65c8/IDA-1.4.4j for ); Thu, 1 Sep 1994 18:07:52 +0200 Received: from letterbox.rl.ac.uk by ib.rl.ac.uk (IBM VM SMTP V2R1) with TCP; Thu, 01 Sep 94 17:07:33 BST Received: from jkr.cc.rl.ac.uk by letterbox.rl.ac.uk with SMTP (PP) id ; Thu, 1 Sep 1994 17:04:47 +0100 Received: by jkr.cc.rl.ac.uk (4.1/SMI-4.1) id AA05723; Thu, 1 Sep 94 17:07:04 BST Date: Thu, 1 Sep 94 17:07:04 BST From: jkr@letterbox.rl.ac.uk (John Reid) Message-Id: <9409011607.AA05723@jkr.cc.rl.ac.uk> To: J.L.Schonfelder@liverpool.ac.uk Subject: Re: (SC22WG5.625) Letter Ballot on ENABLE proposal Cc: SC22WG5@dkuug.dk X-Charset: ASCII X-Char-Esc: 29 Lawrie, you seem to have misunderstood the ballot. It is an X3J3 ballot, not a WG5 ballot. This is what WG5 decided: ............................................................................ E14. Content of the 1995 Revision That WG5 requires that the technical content of the next revision of Fortran include: - the approved items in the Defect Index, with any corrections thereto, - the approved items in document WG5-N995, that is: MAXLOC & MINLOC enhancements, NAMELIST comments, minimal field widths, FORALL, PURE procedures, object initialization, removal of conflicts with IEC 559, CPU_TIME, nested WHERE, user-defined functions in specifications, with any corrections thereto, - the following additional items: language evolution items (WG5-N1048) ENABLE construct (WG5-N1042), allocatable arrays as structure components (WG5-N1040), optional generic-spec on END INTERFACE (WG5-N1017). If the technical work for any item cannot be completed in the time established for submitting the CD, WG5 requests X3J3 to contact the WG5 convenor at the earliest opportunity for resolution of the situation by the WG5 management committee. Individual vote: 21 yes - 2 no - 1 abstain Country vote: 6 yes - 0 no - 0 abstain ............................................................................ X3J3 is charged with completing the technical work, which includes identifying any technical flaws and dealing with them. WG5 in Edinburgh was very determined that the schedule and technical content should be adhered to. > > 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. See paragraph ahead of comment 1. This is not an appropriate comment with an X3J3 vote. > > 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). > See paragraph ahead of comment 1. This is not an appropriate comment with an X3J3 vote, but I will reply. This was carefully considered in Edinburgh and changes were made to allow the addition of user conditions with local scope in F2000. > 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. Strictly speaking, the decision was made in Edinburgh and we should stick with it. One merit of the present rule is that it is restrictive and could be broadened in 2000. However, I do not see it as a big issue. The wording about what is undefined would need to be altered if we allowed these transfers, which would not be very difficult. What do other people think? > > 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. This is a decision that was made consciously by wg5 in Edinburgh and we should not change it. > > 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. > Exactly such a mapping is how most implementors will treat this. The point is already covered by item (6) in 1.3.2. > 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. Actually we are very near this now. Only INSUFFICIENT_STORAGE always signals outside enables. This is because we need to cover the important case of a failure while executing the specification statements. > 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. This idea has not been discussed and I find it quite attractive. What do others think? > 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. I believe that the present proposal meets these aims. > > 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. Agreed, but I see no need to ban it. Changing the inner enable stmt to ENABLE(cond1,cond2) would give equivalent code. Allowing extra conditions on handle stmts is useful to cover their being raised during a procedure call when the overheads of enabling them in line are not wanted. See Example 9. > 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 See paragraph ahead of comment 1. This was considered about a year ago and rejected because of the indeterminacy when more than one condition is signalling. > > 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. Yes, a few more edits are needed. > > 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. See paragraph ahead of comment 1. This is not an appropriate comment with an X3J3 vote. It would be a valid reason for a NO WG5 vote, but it is too late for this. I can find nothing to justify a NO x3j3 vote. Best wishes, John.