Path: utzoo!attcan!uunet!dino!ux1.cso.uiuc.edu!harriett!hirchert
From: hirchert@harriett.ncsa.uiuc.edu (Kurt Hirchert)
Newsgroups: comp.lang.fortran
Subject: Re: Fortran Extended Standard
Message-ID: <1990Oct12.221353.15510@ux1.cso.uiuc.edu>
Date: 12 Oct 90 22:13:53 GMT
References: <1990Oct9.213414.19147@hamblin.math.byu.edu> <65400@lanl.gov>
Sender: news@ux1.cso.uiuc.edu (News)
Reply-To: hirchert@harriett.ncsa.uiuc.edu (Kurt Hirchert)
Organization: National Center for Supercomputing Applications
Lines: 70

In article <65400@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>I haven't received the responses to my comments yet.  I already
>know that they were ignored.  I expect them not to be directly
>answered either.  That's what the responses to the first public
>review did - most of the 'answers' were of the form "the committee
>chose not to do that".  I could tell that much from reading the
>new proposals.  What the public review responses should contain
>is sensible explanations of _why_ the committee chose to do what
>it did.  It's hard to imagine technical justifications for a number
>of the things that the committee has chosen to do.
>
>Oh well, one more round.  I don't suppose they'll listen this
>time either - nor explain why they didn't.
>
>J. Giles

I don't know that this will make you any happier, but let me try to
explain why responses tend to come out like that:

1. Once the first draft is put out, it takes a 2/3 vote to change
   _anything_ in it, so all it takes is 1/3 of the committee not to
   like your suggestion, and it won't happen.  They don't have to
   agree on why they don't like your suggestion.  1/6 of the committee
   might think it does too much and a 1/6 might think it does too
   little.  All this can make it very difficult for the person assigned
   to write your response to say anything sensible.

2. It also takes a 2/3 vote to approve your response.  This tends to
   result in responses being very bland, because otherwise too many
   people on the committee might complain that it doesn't represent
   their personal point of view and vote against it.  The fact that
   the committee chose not to act on your suggestion is clear.  The
   reason may be contested.

3. The sheer volume of comments works against getting well written
   responses.  Either you end up with a generic response for the
   subject of your comment, in which case it probably doesn't answer
   each of your points, or one is specially written for you, in which
   case the person writing it probably didn't have time to write more
   than a relatively superficial response.  In many cases, this
   doesn't really do justice to either your original suggestion or the
   consideration we gave it.

4. On a standard as large as a language standard, the amount of work
   that goes into creating even the first draft standard is so large
   that you must have a very strong point (or a lot of people saying
   the same thing) in order for the committee to accept the work
   involved in making a change.  (You enhance the likelihood of your
   suggestion be accepted if you can show how to implement your
   suggestion editorially as well as technically.)  If your really
   want to significantly affect what ends up in a draft language
   standard, work with the committee informally well before the first
   draft is released for public consumption.

As a practical matter, if you really want to know why a language
committee did something, ask an individual on that committee - his or
her response is more likely to be what you want than the official
response.  If you are concerned about bias, ask individuals with
opposing points of view and compare the responses.

If you really want a committee to seriously consider a suggestion,
either visit that committee and sell the idea to them one person at a
time, or find a champion on that committee who will do that for you.

I had many of the same frustrations as you about X3J3's responses to
my comment on FORTRAN 77 when it was a draft standard.  That's why I
joined the committee for the Fortran 8x (now Fortran 90) work.
--
Kurt W. Hirchert     hirchert@ncsa.uiuc.edu
National Center for Supercomputing Applications