From owner-sc22wg5@dkuug.dk Wed Mar 31 23:06:55 2004 Received: (from majordom@localhost) by dkuug.dk (8.12.10/8.9.2) id i2VL6tVh094437 for sc22wg5-domo; Wed, 31 Mar 2004 23:06:55 +0200 (CEST) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from math.jpl.nasa.gov (math.jpl.nasa.gov [137.79.7.57]) by dkuug.dk (8.12.10/8.9.2) with ESMTP id i2VL6jE7094427 for ; Wed, 31 Mar 2004 23:06:49 +0200 (CEST) (envelope-from vsnyder@mls.jpl.nasa.gov) Received: from math.jpl.nasa.gov (localhost.localdomain [127.0.0.1]) by math.jpl.nasa.gov (8.12.10/8.12.10) with ESMTP id i2VL6jdc024353 for ; Wed, 31 Mar 2004 13:06:45 -0800 Received: from math.jpl.nasa.gov (vsnyder@localhost) by math.jpl.nasa.gov (8.12.10/8.12.10/Submit) with ESMTP id i2VL6jla024349 for ; Wed, 31 Mar 2004 13:06:45 -0800 Message-Id: <200403312106.i2VL6jla024349@math.jpl.nasa.gov> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: inbox To: sc22wg5@dkuug.dk Reply-to: Van.Snyder@jpl.nasa.gov Subject: Re: (j3.2004) (SC22WG5.3093) Plans for the next revision In-Reply-To: Your message of "Tue, 30 Mar 2004 13:05:50 PST." <200403302105.i2UL57Dg076381@dkuug.dk> From: Van.Snyder@jpl.nasa.gov Mime-Version: 1.0 Content-Type: text/plain Date: Wed, 31 Mar 2004 13:06:45 -0800 X-Spam-Score: 0.339 () NO_REAL_NAME Sender: owner-sc22wg5@dkuug.dk Precedence: bulk I have to agree with Richard Maine that John's proposed schedule doesn't leave room for any magnificent feature additions of the scope of object- oriented programming. I disagree, however, that the totality of features proposed and not rejected as of the end of meeting 167 would constitute a revision of the same scope as Fortran 2003. The two major features, Units and Generic Programming, fall in scope somewhere between DTIO and C interoperability -- closer to the small end of that range, in my opinion. Named subranges of integers falls just below that magnitude. Most of the other features, at least most of the ones that I proposed and that didn't get rejected, are in the trivial-to-moderate range, with most clustered around "minor" and a large number at the "trivial" end. The number of proposals is large, but the totality of their magnitude is less than the magnitude of what we accomplished in the 2003 revision. I agree that there are those who will want to talk some of them to death, and that this will be time consuming. Much of our time during the 2003 development was given over to posturing and gossiping. If we were to eschew that and get down to serious work more often, I would be greatly surprised if we could not completely dispatch five or ten of the trivial- to-moderate proposals per meeting, on average. Take, for example, 04-177, which proposes to remove six words from the standard, or 04-189, which will result in removing one syntax term from R210, R1107 and R448. Do these really count as entire "feature" proposals, against the advocated budget of twenty or so? Even if we shout at each other for an hour each, we could still do twenty proposals of this scope in one meeting. We don't have twenty of these to do, but there are many that aren't tremendously larger. 04-157, 04-169 and 04-187 come immediately to mind. Sure, implementors will have some work to do to revise their processors to comply with the revised standard, but in at least a moderate fraction of the cases, and depending on the organization of the individual processors, the work will consist of removing the testing for a restriction, and verifying that the processor still works after doing so, rather than developing new methods and data structures. Others will be of the form "Aha! Proposal X for Fortran 2009 applies in case A in exactly the same way that Proposal Y in Fortran 90 applied to case B." 04-156 is an example of this type. We should try to put proposals into a rough priority order, maybe in blocks instead of individually. Then work on the most important ones first, then the next most important, etc. I don't think we ought to prohibit work on less important ones just because more important ones are not complete. As Richard has pointed out, some contemplation will be necessary to make sure we get things right. The more important proposals will tend to be the larger ones, so different parts of them will be ripe for action at different times. It would be better to work on minor proposals than to go home on Wednesday afternoon if we run out of ripe work for the "big twenty." This is how we got enough done in the 2003 revision to fill John's 38-page N1579 *summary* of our accomplishments. Given that none of the proposals so far advanced for the next revision even remotely approach the complexity of the object-oriented programming features added in 2003, I believe we can and should do enough to fill another 38-page summary -- of just as many or more, but simpler, new features -- during the next five -- not eight -- years. Rather than saying "Prohibit in advance doing more than twenty things, no matter how trivial they are," I believe we should try to get as much done within the schedule as we can. We can sketch out the twenty or so most important ones, and work on them with higher priority, but we should then allow ourselves to do more things if the schedule allows. That doesn't mean we can't do any work at all on any minor thing until all of the work on all of the "big twenty" is complete. It means we can't work on minor things at a particular meeting until all the work that **is ripe for action** on the "big twenty" **at that meeting** is complete. It means we can work on "minor" things **at any meeting**, but only after all of the "really important" stuff that we can do is done. -- Van Snyder | What fraction of Americans believe Van.Snyder@jpl.nasa.gov | Wrestling is real and NASA is fake? Any alleged opinions are my own and have not been approved or disapproved by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else.