From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Thu Jan 28 20:39:22 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 3C6BC358720; Thu, 28 Jan 2016 20:39:22 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from mail.jpl.nasa.gov (mailhost.jpl.nasa.gov [128.149.139.109]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.open-std.org (Postfix) with ESMTP id 09FB2356F47 for ; Thu, 28 Jan 2016 20:39:14 +0100 (CET) Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id u0SJd8Eq027508 (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128 bits) verified NO); Thu, 28 Jan 2016 11:39:11 -0800 Subject: Re: (j3.2006) (SC22WG5.5656) [ukfortran] Straw ballot on second draft corrigendum4 From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: fortran standards email list for J3 Cc: WG5 In-Reply-To: <20160128084819.5A04435852E@www.open-std.org> References: <20160121143417.3C8EF358651@www.open-std.org> <20160128084819.5A04435852E@www.open-std.org> Content-Type: text/plain; charset="ISO-8859-1" Organization: Yes Date: Thu, 28 Jan 2016 11:39:08 -0800 Message-ID: <1454009948.6222.124.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.32.3 (2.32.3-34.el6) Content-Transfer-Encoding: 7bit X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk We're now using (or going to use) the term "active image" instead of "non-stopped image". Should the two occurrences (6.7.1.2 and 6.7.3.2) of "non-stopped image" be "active image"? On Thu, 2016-01-28 at 17:49 +0900, Cohen Malcolm wrote: > This is an interim vote. I might have other changes to suggest later (I am > only 1/4 of the way through...). > > >Please answer the following question "Is N2095, with the references and > >notes removed, acceptable for submission to SC22 for publication as > >Corrigendum 4 for Fortran 2008?" in one of these ways. > > > >1) Yes. > >2) Yes, but I recommend the following changes. > > Yes, but I recommend the following changes. > > >3) No, for the following reasons. > >4) Abstain. > > CHANGES: > (1) In the edit for F08/0131 (page xvi), after "A contiguous array" insert > the word "variable". This is because the sentence later says "provided the > variable ..." and this is meant to apply both to the contiguous array or the > scalar character variable. > (2) Same edit, slightly later in the sentence, change "kind and kind type > parameter" to "type and kind type parameter (if any)". This is obviously > what the interp was talking about - the edit should not be insisting that > the kind be interoperable twice. The "(if any)" is because I think this can > apply when the array is of a BIND(C) type, which has no type parameter. > (3) In the edit for F08/0127, change "is permitted to" to "can", i.e. the > replacement text should read "A free form continuation line can begin with > ...". Reason: the Introduction is non-normative so we are not allowed to > have requirements here. > (4) In the edit for F08/0124, the location should be "Subclause 1.3", and > the instruction should be "After the definition of parent component > (1.3.33.2), insert a new term:", as although definitions use the same > numbering scheme as subclauses, they are not actually subclauses: see ISO > directives part 2 which says > "terms and definitions are a definitions list and not a series of > subclauses". > (5) Subclause 4.3.1.3 > Change "the derived-type-def of the specified derived type" to "its > derived-type-def". > Reason: immediately prior to this we've established that we are talking > about "that derived type" (which is "the derived type [] specified in the > FUNCTION statement"); switching from "that derived type" to "the specified > derived type" implies there is some other specified derived type (which is > not the case) as well as being unnecessarily long-winded platitudinous > ponderosity. "its" is more than adequate! > (6) It does not really matter for a corrigendum, but the edit for 5.3.4 > inserts a disjunction into a paragraph that already has a conjunction, > without adding a comma for disambiguation. One can deduce the parse from > the fact that it has bullet points, but it would be slightly nicer if there > were also a comma before the "and" at the end of the first bullet point. (I > will have to remember this when applying the changes to 007!) > > Cheers,