From owner-sc22wg5 Tue Jul 16 19:47:15 2002 Received: from mailhub.dfrc.nasa.gov (mailhub.dfrc.nasa.gov [130.134.81.12]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id TAA47508 for ; Tue, 16 Jul 2002 19:47:10 +0200 (CEST) (envelope-from maine@altair.dfrc.nasa.gov) Received: from mail.dfrc.nasa.gov by mailhub.dfrc.nasa.gov with ESMTP for SC22WG5@dkuug.dk; Tue, 16 Jul 2002 10:42:51 -0700 Received: from altair.dfrc.nasa.gov ([130.134.164.107]) by mail.dfrc.nasa.gov (Post.Office MTA v3.5.3 release 223 ID# 0-71686U2500L200S0V35) with ESMTP id gov for ; Tue, 16 Jul 2002 10:37:54 -0700 Received: (from maine@localhost) by altair.dfrc.nasa.gov (8.11.6/8.11.6) id g6GHboI05795; Tue, 16 Jul 2002 10:37:50 -0700 From: Richard Maine MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <15668.23022.579233.380735@altair.dfrc.nasa.gov> Date: Tue, 16 Jul 2002 10:37:50 -0700 To: SC22WG5@dkuug.dk Subject: (SC22WG5.2483) Edits to the draft standard In-Reply-To: <200207161629.SAA47136@dkuug.dk> References: <200207161629.SAA47136@dkuug.dk> X-Mailer: VM 7.00 under 21.4 (patch 6) "Common Lisp" XEmacs Lucid John Reid writes: > 43:10-11. Change the constraint to 'Each bound in the > shall be an initialization expression (7.1.7). > [This is the wording in Corrigendum 1 to F95. I believe that the > present wording will lead to an inconsistency with f95. See also C550 > on p. 79.] > > 43:14-16. Change 'a specification ... thereof' to 'an initialization > expression'. [See previous edit.] Though there may be problems with the wording in 02-007r2 (if nothing else, it reads awkwardly to say "each bound...shall not contain"), I think the above edits are wrong. There is an intentional difference from f95 because of a new feature in f2k. Namely, component array bounds may depend on type parameters in f2k - even nonkind type parameters. Indeed, one of the major uses of nonkind type parameters would presumably be as array bounds; disallowing this would be to throw out a significant change in requirements (and probably contradicts things elsewhere in the draft). If the wording needs fixing (which it well might), we need to be sur ethat the fix doesn't disallow this. Does seem like C550 needs work in this area, I'd agree. > 411:34. Delete 'name'. [We need to cover variables that are > subobjects.] Hmm. Perhaps instead change "name" to "designator". I don't think the variable itself appears in the source code - just the name or other designator of the variable. We are already pretty bad throughout the document about confusing when we are talking about an entity and when we are talking about the name (or other designator) of the entity. I despair of fixing all cases of this, but I like to avoid adding new ones (at least where I notice). I notice that your edits on pg 81 overlap with some edits in Van's paper 02-213 (which were partly prompted by my comments in 02-209). I'll let the two of you (and J3/WG5) work out what combination of the edits proposed by you and by Van seems appropriate...but please don't pass both sets, failing to notice the overlap, and leave it to me to reconcile them. No comment on the rest of the edits in this paper. Some I agreed with and some I didn't study well enough to have a comment yet. -- Richard Maine | Good judgment comes from experience; maine@altair.dfrc.nasa.gov | experience comes from bad judgment. | -- Mark Twain