(j3.2006) Process for 200

[Van Snyder]

After 199, I caught he11 from some of my sponsors for failing to advance
their agenda, because they didn't see what they considered to be
sufficient evidence of it in the minutes.  This came right after I had
gotten, for the first time, a specific account number for Fortran
participation, rather than my group's project paying for the entire
laboratory to be represented.  They threatened to cancel it.  I had
already been told that my group would not be allowed to pay my INCITS
fee, or for me to go to Delft.  They see my most important job on the
committee as advocating for features during the requirements phase, so
if they don't see that happening they don't want to pay.

Sh1t flows downhill, but I should have kept it from flowing right past
me onto the committee, and especially onto Malcolm.

To avoid this again, can we use the 2004 process and format of a
separate short paper for each proposal, with plenary acting as JOR?

My sponsors are still keen to advance the proposals from 12-195 that
don't appear in the minutes.  I don't yet have details of all the
reasons for wanting all of them.  The ones I haven't talked them out of
yet are:

1. Allow data-ref%binding-name in pointer assignment and actual
arguments.  I explained the reason for this last week.

2. <access-spec> on a <procedure-stmt>, for the same reason as wanting
<access-spec> on enumerator declarations (fewer statements in the
specification part of the module).

3. Optional arguments on procedures that define operations or
assignment.  At least to avoid writing wrappers, but there might be
other reasons I haven't been told yet.

3a. #3 with specification in the <procedure-stmt> of the values to be
associated with optional arguments after the second argument.  They'd
like more general partial application (i.e., not just for operators and
assignment), but I think I've talked them out of that.

4. SIZE= without ADVANCE=.  I remember being convinced of the reason for
this more than twenty years ago, but I can't find the example now.

5. Inquiry functions, e.g., KIND(x%a%b%c) etc. with both a and b arrays,
or with either one a disassociated pointer.

6. Substrings of character arrays.

7. Procedure arguments to specification functions.  Again at least to
avoid writing wrappers, but there might be other reasons I haven't been
told yet.

8. Caseless INDEX, SCAN, VERIFY.

9. UPPER_CASE and LOWER_CASE.

10. Lazy MERGE, a new "function" (say IF) with lazy evaluation
semantics, or a distfix operator, to embed decisions within expressions,
especially specification expressions.  My sponsors are especially keen
for a two-argument (one consequent) version to compute whether an actual
argument is present.  They regard the use of a disassociated pointer
associated with a nonpointer optional argument as a kludge, don't like
what the pointer and target attributes do to optimization, and don't
like that it doesn't work for pointer arguments.

11. MATMUL with more than 2 arguments.  A colleague has a need to
multiply four matrices of varying dimensions, and might soon need to
multiply more.  Optimal and suboptimal parenthesization can have vastly
different costs.  A simple dynamic-programming problem can compute the
optimal parenthesization, but the size of the IF block needed after
computing that solution grows very rapidly.  For four matrices it's
"only" 14.  For five matrices it's "only" 42.  For n matrices it's
(2n!)/((n+1)!n!).  I talked them out of DOT_PRODUCT with more than 2
arguments, even though they weren't convinced that processors would
optimize SUM(A*B*C...*Z) as well.

12. Rank 1 extent R array as single bounds specifier for rank-R array
declaration.  To justify this, I was shown a subprogram with 130
automatic arrays, for which each declaration was three or four lines;
they would have been one line each with this proposal.  I suggested they
use a single statement, with an explicit DIMENSION attribute specifier,
for each subset that had the same bounds and type.  They showed me a
style manual that required a separate statement, with comments, for each
declaration.

13. Rank K+1 extent R,n1,n2,...nk array as single subscript for rank-R
array, producing a rank K extent n1,n2,...nk object that can appear both
as a reference and in a variable-definition context -- except maybe as
an actual argument (scatter/gather).

I've told them that 12, 13, maybe 3a, maybe 6, maybe 11, and 10
depending on how it's proposed to be done, are almost certainly out of
scope, but they haven't given up on them.

They are also keen to see some of the proposals that fell off the train
in 2004 revisited.  I've told them that coroutines, updaters,
enhancements of the type system (new types that are not aliases,
enumerations (ordered and unordered) that are new types, subranges of
integers,...), and block-structured exception handling, are almost
certainly out of scope, but I haven't convinced them about several of
the little ones.

I'd like to be able to show them the minutes to prove that their
proposals were considered.  They objected to reading through 12-183r5.
Seeing "no further action" for 12-195 set off a firestorm.  The best way
to convince them that it's worth their expense to send me to meetings
would be to put each proposal in a separate paper, as we did in 2004, so
that I can give them a spreadsheet like we used in 2004, or a list of
paper numbers, with subject lines alone, and the vote on each one.

I'll prepare papers in the 2004 format for the ones from 12-195 that
were new, and either revise 2004 papers or ask for reconsideration of
them, for the ones from 2004 that I can't talk my sponsors out of.  I
hope we use the 2004 method of plenary acting as JOR, instead of
pre-filtering in subgroup.