(j3.2006) (SC22WG5.4843) RE: Process for 200 - as proposed by Van
Van Snyder
van.snyder
Sat Nov 24 16:06:08 EST 2012
I don't object to filtering proposals. We did a lot of it in 2004. I
did not object to the process, or quibble with the outcomes after the
proposals were fairly considered. I object to the process used at 199.
Whether a proposal addresses a deficiency or inconsistency, or
constitutes a new feature, and whether it is sufficiently simple, are
questions that ought to be decided by votes that are more decisive than
1-1-1.
I have never suggested that the units proposal is simple. The paper in
the Tutorials directory is in the form of a TS. It is not a proposal
for inclusion in the next revision.
The committee might remember that my early proposals for 2003 and 2008
were presented in the form of a single paper with several proposals.
This was considered to be undesirable. The only acceptable form became
a separate paper for each proposal.
There are several advantages to having a separate paper for each
proposal, the simplest being easy reference in the minutes, discussion,
and ultimately the work plan. If a proposal gets added to or removed
from the work plan, a comprehensive paper needs to be edited. Proposals
in separate papers allow for more complete discussion of the problems
addressed. Proposals collected into a single paper either don't include
adequate discussion, or the collected paper becomes intimidatingly
massive.
I don't remember Stan advancing arguments against one of my proposals
that had been discussed in the paper. There have been cases where
members appeared not to have taken the time or had the interest to read
my proposals, but were nonetheless eager to criticize them. It's
entirely possible in those cases that my descriptions had been carefully
studied, but were inadequate.
On Thu, 2012-11-22 at 20:28 +0000, Whitlock, Stan wrote:
> I'm opposed to using this process at m200. I wasn't at the Toronto but the minutes N1926 say:
>
> 10.1 Goals for 2012-2014 on Thursday
> Revision of the strategic plan was discussed considering the UK position paper N1923. It was agreed that we
> should aim to produce a TS on further coarray features as soon as possible, and to produce a revision of the
> standard that consolidates the two Technical Specifications, corrigenda and editorial improvements approximately
> two years after that. This revision would concentrate on consolidation and removal of small inconsistencies in
> existing features and their interaction, and not add any large new features.
>
> and the resolutions N1927 say:
>
> M6. Strategic Plan for WG5
> WG5 adopts document WG5-N1925 as its strategic schedule for the next three years. WG5 resolves that the next
> revision shall consist of a consolidation of the agreed editorial improvements, corrigenda and the two Technical
> Specifications into the main standard, plus the removal of simple deficiencies in, and discrepancies between, existing
> facilities. The intent is to resolve issues that have been created by successive extensions to Fortran, while minimizing
> impact on the standard document, implementors and other users. The criterion for deciding whether a change is
> simple is that it requires no more than a small amount of editorial effort and no more than a small amount of
> implementation effort. Furthermore, WG5 resolves that no new significant language extensions, beyond those
> mentioned in these resolutions, will be considered until the process described in this resolution is complete.
>
> What part of this is questionable? It says "no new features" several different ways:
>
> * the removal of simple deficiencies in, and discrepancies between, existing facilities
> * The criterion for deciding whether a change is simple is that it requires no more than a small amount of editorial
> effort and no more than a small amount of implementation effort.
> * WG5 resolves that no new significant language extensions, beyond those mentioned in these resolutions, will be
> considered until the process described in this resolution is complete.
>
> There was no extensive process put in place by WG5 to allow arbitrary {even small} new features to be considered for F2015 like there was for F2008 that Van extolls so. WG5 has decided and J3 has its marching orders. JOR at m199 tried to put an inventory in place in 12-183r4 so we knew what "simple" changes were considered with what outcome. 12-195 definitely needed to be filtered because it contained large, new features that were not to be considered.
>
> It appears Van will give a tutorial at m200 on UNITS to at least the USTAG if not J3. I resent the implication that if I don't agree that UNITS is the greatest thing since sliced bread that I either didn't read the proposal or understand it. I've done both. It's not within the WG5 guidance - UNITS is not simple; it's not small; it's not a deficiency or discrepancy between existing features; it's a new significant language extension. The only outcome is that UNITS won't be considered for F2015. End of story. So why are we doing this?
>
> I haven't seen the agenda for Delft yet so I don't know if WG5 will be entertaining every country's list of "simple changes" for F2015. But I'm sure WG5 won't be considering new significant language extensions for F2015.
>
> /Stan
>
> -----Original Message-----
> From: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Van Snyder
> Sent: Tuesday, November 20, 2012 10:58 PM
> To: j3
> Subject: (j3.2006) Process for 200
>
> 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.
>
>
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
More information about the J3
mailing list