(j3.2006) (SC22WG5.5914) Preview of possible feature survey

Van Snyder Van.Snyder
Wed Jul 12 16:18:18 EDT 2017


On Wed, 2017-07-12 at 18:52 +0000, Bill Long wrote:
> It might also be helpful to limit the number of proposals from any one
> individual, which would force him/her to focus on what is really
> important.  A number like 5 seems reasonable. I don?t recall more that
> that number of acceptable proposals from anyone in the past.  It could
> help cut down on the amount of commitee time spent weed-whacking.

This is clearly aimed at me.

Limiting the number of submissions to the number of previously accepted
proposals is stupid and unfair (has Tom Knox had any accepted proposals
yet?).

And five is stupid and unfair.

I proposed 79 items in 04-265.xls. In 05-145r3, 25 of them were still on
the to-be-considered list.  Dan proposed 41 items.  Walt proposed 23.
Aleks proposed eleven.

In 05-010, five of my proposals were still on the Required list, six
were on the Allowed list (and got implemented), and my proposal for an
alternative to one on the Allowed list (asterisk repeat instead of CSV)
was implemented.  BLOCK construct was rejected but then found to be
indispensable for macros, which were eventually rejected.  Fortunately,
it survived.  IMPLICIT NOEXTERNAL was rejected in 2005, but implemented
in the current revision.  Functionality of a GET_LUN intrinsic
reappeared as NEWUNIT in the OPEN statement.  The GENERIC statement was
implemented in the current revision.  Parts of a proposal for contiguity
were implemented in a different form.  SIZE= for advancing I/O was
rejected for 2008 but accepted for 2015.  So at least eighteen of my
original 79 proposals in 2004, some of which were rejected but later
revived, were ultimately implemented in one form or another.  Some of
the rejected ones have been proposed by others for the next revision,
e.g., parameterized modules.

We had an organized process in 2004-05.  It took four J3 meetings to
sort through the requests, in plenary, not subgroup, a process I
consider to be more fair than the 2015 process.  The effort was not
wasted.  The process for 2015 was disorganized, not recorded as
concisely and understandably as Stan did using the Excel spreadsheets in
2004-05, and proposals should not have been subject to subgroup veto
without plenary discussion.

Twelve of my proposals from 97-114r2 were eventually accepted in various
forms.  Protected types were considered and rejected again, but if
accepted would have simplified the duplicative discussion of lock and
event types (and been useful to users).  Medium-grain parallelism
(fork/join construct, asynchronous block construct) is probably on the
table again.

I have used Fortran since 1963.  Since 1976, when DoD asked my group to
review five editions of requirements and four proposals for what became
Ada, my colleagues have been giving me suggestions for improvement to
Fortran.  My list now numbers about 155 items.  I plan to submit all of
them, one paper each, in the format John designed for 2008, or an agreed
revision of that format.

I joined J3 to support my user community, whose desires are to reduce
labor cost and increase reliability without compromising efficiency, not
to obstruct progress to limit my workload, standardize my extensions, or
get anti-trust protection.





More information about the J3 mailing list