On Thu, 2016-03-24 at 08:35 -0400, Tom Clune wrote:

> The president of the committee has indicated that the process will
> rely heavily on _use cases_.   I.e.  the proposer will need to explain
> likely/relevant scenarios for which the new feature significantly
> improves the implementation.

I have 58 pages of use cases, collected from more than 600 developers at
JPL during the last 53 years of using Fortran.  The table of contents is
nearly four pages.  Many of the proposals have been repeatedly requested
by other Fortran user communities.  The fact that the list hasn't
dwindled suggests that use cases don't actually carry much weight.
(Actually, item 2.7.7.7 has been implemented in the currently-proposed
revision; I could remove five lines from the paper.)  I'm happy to send
it to anybody who wants it.

When Ada was still called DoD\1 (about 1976), the organization at DoD
that became AJPO asked our group at JPL to review the requirements and
specifications.  Among numerous other comments, on every version of the
requirements from Strawman to Steelman, as well as on the final Red,
Green, Blue, and Yellow proposals, we proposed that a high-reliability
language ought to include a system of measurement units (actually
dimensions, so that kilometers could be distinguished from centimeters).
Col. Whittaker said "Huh?  Why would we want that?"

We proposed it for Fortran in about 1997, and perhaps as early as 1986
(I've lost my correspondence concerning Fortran 90 development).  After
the Mars Climate Orbiter arrived 67 kilometers too low at Mars because
of an error in measurement dimensions for momentum (pound seconds
instead of Newton seconds), resulting in the loss of a $300 million
mission, I developed a proposal in the form of a Type II Technical
Report -- now called a Technical Specification.  Despite that
spectacularly expensive use case, the proposal has met an unwelcome
reception several times.  So much for the "use cases" excuse.

At the last two WG5 meetings, I asked again for permission for a project
to produce a Technical Specification, and was rebuffed again.  At the
most recent (Delft) meeting, I offered to remove the paragraph that
promises to incorporate it into the next revision, so that developers
could add it to their product (or not) depending upon their customers'
priorities.  If the "piling more work on vendors" excuse were real, that
should have had some effect, but it was met with silence.

I pointed out that my sponsors want to know why a feature that is so
obviously useful in a language oriented toward solving scientific and
engineering problems isn't wanted.  I was twice promised that a response
would be forthcoming, but so far we still have no clue what the
resistance is. 

This suggests that even one spectacularly expensive use case, and
continuing use cases having significant but diffused expense, do not
actually carry much weight.  (Have you ever spent a week tracking down a
mysterious bug, only to discover that your program has sin(latitude)
instead of sin(latitude*deg2rad) in one place?)  The "use case" excuse
looks more like a smoke screen.

At JPL, we review the proposal from time to time and have found no
reason to change anything for several years.  Between internal JPL
reviews, and informal reviews by J3 and WG5 members, the proposal now
has seen 18 revisions.  We believe the proposal is complete.  The only
action necessary for J3 and WG5 is to read it once more and vote on it,
then for ISO to publish it.  A total of about one hour of plenary time
would be needed.