From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Thu Nov 22 21:29:26 2012 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id E698F356976; Thu, 22 Nov 2012 21:29:25 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from mga14.intel.com (mga14.intel.com [143.182.124.37]) by www.open-std.org (Postfix) with ESMTP id B56183567F0 for ; Thu, 22 Nov 2012 21:29:22 +0100 (CET) Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 22 Nov 2012 12:29:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.83,302,1352102400"; d="scan'208";a="171497299" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by AZSMGA002.ch.intel.com with ESMTP; 22 Nov 2012 12:28:53 -0800 Received: from orsmsx107.amr.corp.intel.com ([169.254.10.151]) by ORSMSX104.amr.corp.intel.com ([169.254.3.56]) with mapi id 14.01.0355.002; Thu, 22 Nov 2012 12:28:53 -0800 From: "Whitlock, Stan" To: WG5 CC: "Whitlock, Stan" Subject: RE: (j3.2006) Process for 200 - as proposed by Van Thread-Topic: (j3.2006) Process for 200 - as proposed by Van Thread-Index: Ac3I6ZzzXALE5GOMSx+3Zju4rLgpQQ== Date: Thu, 22 Nov 2012 20:28:52 +0000 Message-ID: <4AA982B1265F43408480F737BE12F4D30D76A9D4@ORSMSX107.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-sc22wg5@open-std.org Precedence: bulk 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 p= aper 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 an= d editorial improvements approximately two years after that. This revision would concentrate on consolidation an= d removal of small inconsistencies in existing features and their interaction, and not add any large new feature= s. 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 improvem= ents, corrigenda and the two Technical Specifications into the main standard, plus the removal of simple deficien= cies in, and discrepancies between, existing facilities. The intent is to resolve issues that have been created by succ= essive extensions to Fortran, while minimizing impact on the standard document, implementors and other users. The criter= ion 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 descr= ibed in this resolution is complete. What part of this is questionable? It says "no new features" several diffe= rent ways: * the removal of simple deficiencies in, and discrepancies between, exis= ting facilities * The criterion for deciding whether a change is simple is that it requi= res 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 th= at 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 "simpl= e" changes were considered with what outcome. 12-195 definitely needed to = be filtered because it contained large, new features that were not to be co= nsidered. 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 th= e 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 - UNIT= S is not simple; it's not small; it's not a deficiency or discrepancy bet= ween existing features; it's a new significant language extension. The on= ly 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 ente= rtaining 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@mailman.j3-fortran.org [mailto:j3-bounces@mailman.j3-fortr= an.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 th= eir agenda, because they didn't see what they considered to be sufficient e= vidence of it in the minutes. This came right after I had gotten, for the = first time, a specific account number for Fortran participation, rather tha= n my group's project paying for the entire laboratory to be represented. T= hey threatened to cancel it. I had already been told that my group would n= ot 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 r= equirements phase, so if they don't see that happening they don't want to p= ay. Sh1t flows downhill, but I should have kept it from flowing right past me o= nto the committee, and especially onto Malcolm. To avoid this again, can we use the 2004 process and format of a separate s= hort 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 wan= ting 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. on a , for the same reason as wanting 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 have= n't been told yet. 3a. #3 with specification in the of the values to be assoc= iated 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=3D without ADVANCE=3D. I remember being convinced of the reason fo= r 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, o= r a distfix operator, to embed decisions within expressions, especially spe= cification 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 nonpoint= er optional argument as a kludge, don't like what the pointer and target at= tributes do to optimization, and don't like that it doesn't work for pointe= r 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 parenthesizati= on, 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 decla= ration. To justify this, I was shown a subprogram with 130 automatic array= s, 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 se= parate statement, with comments, for each declaration. 13. Rank K+1 extent R,n1,n2,...nk array as single subscript for rank-R arra= y, producing a rank K extent n1,n2,...nk object that can appear both as a r= eference 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 o= n 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-struct= ured exception handling, are almost certainly out of scope, but I haven't c= onvinced 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 b= e to put each proposal in a separate paper, as we did in 2004, so that I ca= n 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 n= ew, and either revise 2004 papers or ask for reconsideration of them, for t= he 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@mailman.j3-fortran.org http://mailman.j3-fortran.org/mailman/listinfo/j3