From jwagener@amoco.com Sat Oct 1 06:29:03 1994 Received: from interlock.amoco.com by dkuug.dk with SMTP id AA26798 (5.65c8/IDA-1.4.4j for ); Sat, 1 Oct 1994 17:29:40 +0100 Received: by interlock.amoco.com id AA08765 (InterLock SMTP Gateway 1.1 for sc22wg5@dkuug.dk); Sat, 1 Oct 1994 11:29:27 -0500 Received: by interlock.amoco.com (Internal Mail Agent-3); Sat, 1 Oct 1994 11:29:27 -0500 Received: by interlock.amoco.com (Internal Mail Agent-2); Sat, 1 Oct 1994 11:29:27 -0500 Received: by interlock.amoco.com (Internal Mail Agent-1); Sat, 1 Oct 1994 11:29:27 -0500 From: jwagener@amoco.com X-Openmail-Hops: 1 Date: Sat, 1 Oct 94 11:29:03 -0500 Message-Id: Subject: ENABLE ballot results To: sc22wg5@dkuug.dk X-Charset: ASCII X-Char-Esc: 29 Item Subject: Message text To X3J3 - The results of this ballot are 9 to approve the committee action in Edinburgh and 13 to disapprove that action; therefore the ballot fails. The vote breakdown: J. Adams (for Brainerd) approve G. Barber disapprove K. Bierman approve M. Ellis disapprove R. Hendrickson disapprove J. Himer approve, with comments K. Hirchert approve, with comments R. Kelble approve, with comments D. Levine disapprove R. Maine disapprove J. Martin disapprove D. Mattoon approve L. Moss disapprove M. North approve L. O'Gara disapprove D. Phillimore disapprove L. Rolison disapprove J. Shepherd disapprove M. Snyder disapprove T. Terpstra approve, with comments J. Wagener approve S. Whitlock disapprove As this item was a firm WG5 requirement for Fortran 95, I believe we need to take some time at the Boston meeting to review the (technical) comments associated with this ballot to see if their resolution is feasible or if we need to go into "emergency mode" with WG5. Therefore I will be asking the /JOR subgroup to give priority to this review and make a recommendation to the full committee at the earliest possible time during the week. It is my policy not to revisit an issue once a decision has been made, unless significant new information comes to light. That may now be the case for automatic deallocation. One of the more significant potential technical problem with the ENABLE proposal, it seemed to me in quickly skimming the comments, is the possible impact of automatic deallocation on implementation of ENABLE as it stands (e.g., the implementation impact on "long jump"). If this does turn out to be a problem - let's say the most pressing problem - then one choice we may have is to decide whether to go forward with ENABLE and not automatic deallocation (which was not a firm WG5 requirement), or to stick with the letter ballot results in each case. I will shortly put together and distribute a complete list of the technical comments associated with this ballot. Unlike normal practice, however, I will limit that list to the technical comments and not include the other comments. For example, there were several comments along the lines of a self-fulfilling-prophesy-esque "we shouldn't do this because we don't have time". While that may be true, in the final analysis it is WG5's responsibility to determine whether schedule or content is the more important. Therefore I want us to concentrate on the technical issues, and attempt to determine when ENABLE can be gotten into satisfactory technical shape. I want, therefore, to strongly discourage nontechnical arguments/issues at the meeting. Thus the list that I distribute will be comprehensive in terms of the techical comments, but leave everything else out; of course, I'll have the ballot comments in their entirety for the record, but our committee action in Boston should be entirely concerned with the technical issues. More later. Jerry