From jls@ironwood.cray.com Tue Oct 4 13:21:36 1994 Received: from timbuk.cray.com by dkuug.dk with SMTP id AA21568 (5.65c8/IDA-1.4.4j for ); Wed, 5 Oct 1994 00:21:43 +0100 Received: from sdiv.cray.com (root@ironwood.cray.com [128.162.21.36]) by timbuk.cray.com (8.6.9/8.6.9M) with SMTP id SAA25930; Tue, 4 Oct 1994 18:21:39 -0500 From: jls@ironwood.cray.com Received: from jsteedil.cray.com by sdiv.cray.com (5.0/CRI-5.15.b.orgabbr Sdiv) id AB27804; Tue, 4 Oct 1994 18:21:36 -0500 Date: Tue, 4 Oct 1994 18:21:36 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: jwagener@amoco.com, sc22wg5@dkuug.dk Subject: Re: (SC22WG5.635) ENABLE ballot results Content-Length: 3975 X-Charset: ASCII X-Char-Esc: 29 My recollection was WG5 was pretty clear on holding to schedule and to vary content to meet the schedule. Given that, i think comments about "not enough time" are certainly valid. And, since there are only two J3 meetings to integrate 009 items successfully, it would be unfortunate to redirect too many J3 resources to fixing ENABLE at the expense of getting other features properly integrated. My $0.02 worth. -jon At 4:29 PM 10/1/94, jwagener@amoco.com wrote: >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