From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sun Jul 3 17:40:08 2016 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 BD4A59DB15D; Sun, 3 Jul 2016 17:40:08 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 565 seconds by postgrey-1.34 at www5.open-std.org; Sun, 03 Jul 2016 17:40:06 CEST Received: from ndmsvnpf102.ndc.nasa.gov (NDMSVNPF102.ndc.nasa.gov [198.117.0.152]) by www.open-std.org (Postfix) with ESMTP id D7E653571C2 for ; Sun, 3 Jul 2016 17:40:02 +0200 (CEST) Received: from ndmsppt103.ndc.nasa.gov (ndmsppt103.ndc.nasa.gov [198.117.0.68]) by ndmsvnpf102.ndc.nasa.gov (Postfix) with ESMTP id 94122400434A; Sun, 3 Jul 2016 10:30:35 -0500 (CDT) Received: from NDMSCHT116.ndc.nasa.gov (ndmscht116-pub.ndc.nasa.gov [198.117.0.216]) by ndmsppt103.ndc.nasa.gov (8.15.0.59/8.15.0.59) with ESMTP id u63FUZJS016270; Sun, 3 Jul 2016 10:30:35 -0500 Received: from gs6101-clune.home (96.231.29.147) by smtp02.ndc.nasa.gov (198.117.0.216) with Microsoft SMTP Server (TLS) id 14.3.294.0; Sun, 3 Jul 2016 10:30:34 -0500 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: (j3.2006) (SC22WG5.5743) Units of measure From: Tom Clune In-Reply-To: <20160702202059.B9618358745@www.open-std.org> Date: Sun, 3 Jul 2016 11:30:23 -0400 CC: sc22wg5 Content-Transfer-Encoding: quoted-printable Message-ID: <16B77158-ACBF-49E8-A4DD-1E04A7C59B59@nasa.gov> References: <20160619135920.D0F3F358287@www.open-std.org> <20160629112043.BF09F3587AF@www.open-std.org> <20160629123517.185A635828D@www.open-std.org> <20160629190123.72A8035859B@www.open-std.org> <20160702105054.18596358745@www.open-std.org> <20160702202059.B9618358745@www.open-std.org> To: fortran standards email list for J3 X-Mailer: Apple Mail (2.3124) X-Originating-IP: [96.231.29.147] X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-07-03_11:,, signatures=0 Sender: owner-sc22wg5@open-std.org Precedence: bulk Staying out of the main fray, but I=E2=80=99ll make the case for = =E2=80=9Cslowing the pace=E2=80=9D of the standard. The problem is not so much that the F2003 features were large/difficult = to implement, though they certainly were. Rather the problem was = that different vendors (justifiably) chose to implement differing = features first. This meant that users who required some degree of = portability could not properly exercise the implementations until we = were fairly far down the path of full-implementation. A smaller bite = would have focused the vendors on a common set of features which would = have thereby enabled end-users to have to provide more immediate = feedback. As a different part of this thread points out: when F2003 was ratified = there was enough support for PDT=E2=80=99s and DTIO to be placed in the = standard. Surely they are still on some developers=E2=80=99 lists of = desired features, but quite possibly they would now fall low enough in = priority that other features would be chosen in the standard. =20 Because of these types of concerns (and by way of analogy with most = modern software development approaches), a shorter cycle would provide = the greatest opportunity to ensure that the priority list is optimized = across the Fortran community and implemented in time to make corrections = in the subsequent standard. The lower limit on the time scale for = this cycle is determined by the processes of the committee itself for = reliably incorporating an approved feature. This would appear to be = 2-3 years at the current pace of meetings. Balancing that limit with = the desire to have a meaty enough set of features/improvements would = make the current goal of 5 years seem reasonable. (Would not oppose = shorter cycles myself.) =20 In short, if we (users) pack too much into a revision, we are hurting = ourselves. Yes - I have a laundry list of things I=E2=80=99d like = to see in the standard. But the only way I see to enable a measurable = change in the amount we can place in a single revision would be to have = substantially more investment of time by committee members (more = members, more meetings, longer meetings) _and_ by the vendors whose = development process must impedance match the standards process. Cheers, - Tom > On Jul 2, 2016, at 4:20 PM, Van Snyder = wrote: >=20 > I don't understand how the paragraph quoted from the ISO directives > precludes the possibility of publishing a TS that does not promise to > incorporate the feature in a future standard. Not promising to > incorporate is not the same as promising not to incorporate.=20 >=20 > Bill and others have argued that units support ought to be provided by = a > preprocessor, no matter how unpalatable that is, especially if one has > several users and several developers of the software. If a TS were > published, at least preprocessor vendors could claim compliance to = that, > and would hopefully all provide the same features, in the same way. >=20 > I also don't understand the argument that we shouldn't be ambitious > because vendors found some features of 2003 difficult to implement. = If > we had postponed incorporating them until 2015, nobody would have = given > any thought to how to implement them until now, and they would thereby > not be available until 2025. I don't see any advantage in that. > Indeed, it seems to be a distinct disadvantage. I'm very pleased that > 2003 features are becoming available now, instead of appearing ten = years > after my retirement. >=20 > I've spend my entire half-century career working in an organization > whose motto is "Dare Mighty Things" so perhaps I can be forgiven for > having more ambitions for Fortran than other members seem to have. >=20 > Reliability is extremely important to my organization. We built two > machines that have operated unattended in the harsh deep-space > environment for forty years, and show all signs of lasting at least > another decade. We promised NASA that the Spirit and Opportunity = rovers > would last ninety days on Mars. Opportunity is still working twelve > years after landing. The Spirit rover lasted "only" six years. > Reliability doesn't come without great effort, and every tool to = improve > it is welcome. Is reliability not important to anybody else, or is > everybody who cares about it eager to achieve it without the best = tools > possible? >=20 > JPL is a Federally Funded Research and Development Center, operated by > Caltech. Unlike at least a few government civil-service = organizations, > JPL and Caltech are very careful with taxpayers' money, so labor cost = is > important to us. Reliability doesn't come for free, and every tool = that > helps to reduce the cost of achieving it is welcome. Is labor cost = not > important to anybody else? >=20 > On Sat, 2016-07-02 at 11:50 +0100, John Reid wrote: >> WG5, >>=20 >> N.M. Maclaren wrote: >>> On Jun 29 2016, Bill Long wrote: >>>>>=20 >>>>> Van asks >>>>>=20 >>>>> 2. Did you ask whether my offer to remove the promise to = incorporate the >>>>> specification into a future revision of the standard made a = difference >>>>> in their positions? >>>>>=20 >>>>> For all those that attended the London meeting, I would appreciate = your >>>>> thoughts on this. >>>>>=20 >>>>> I think I should perhaps add a paragraph on 2. I think the = sentiment >>>>> was that it would obviate the whole point of a TS - to define a = feature >>>>> that WG5 intended eventually to include in the standard. >>>>=20 >>>> I agree with John that this is the operational norm for WG5 and = making an >>>> exception here weakens the norm for other proposals. >>>=20 >>> While that is true, there were people who felt that using TSs solely = for >>> that purpose was a mistake. >>=20 >> We have to work within the ISO/IEC JTC 1 rules. The latest directives = say >>=20 >> "When the subject in question is still under development or where for=20= >> any other reason there is the future but not immediate possibility of = an=20 >> agreement to publish an International Standard, the technical = committee=20 >> or subcommittee may decide, by following the procedure set out in = 2.3,=20 >> that the publication of a Technical Specification would be = appropriate." >>=20 >> I have added a paragraph that includes this quotation at the end. I = have >> also split the first paragraph to add a sentence explaining that this=20= >> was proposed as a TS. >>=20 >> Does this document now give a fair summary of why we made the = decision >> in London? >>=20 >> John. >> _______________________________________________ >> J3 mailing list >> J3@mailman.j3-fortran.org >> http://mailman.j3-fortran.org/mailman/listinfo/j3 >=20 >=20 > _______________________________________________ > J3 mailing list > J3@mailman.j3-fortran.org > http://mailman.j3-fortran.org/mailman/listinfo/j3