From owner-sc22wg5@dkuug.dk Thu Jul 17 21:36:11 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h6HJaBMY069611 for sc22wg5-domo; Thu, 17 Jul 2003 21:36:11 +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 mailhub.dfrc.nasa.gov (mailhub.dfrc.nasa.gov [130.134.81.12]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h6HJYZEc069601 for ; Thu, 17 Jul 2003 21:36:07 +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; Thu, 17 Jul 2003 12:31:40 -0700 Received: from altair.dfrc.nasa.gov ([130.134.20.211]) by mail.dfrc.nasa.gov (Post.Office MTA v3.5.3 release 223 ID# 0-71686U2500L200S0V35) with ESMTP id gov for ; Thu, 17 Jul 2003 12:34:27 -0700 Received: by altair.dfrc.nasa.gov (Postfix, from userid 201) id 0381A35093; Thu, 17 Jul 2003 12:34:24 -0700 (PDT) From: Richard Maine MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="V0NHczuRvJ" Content-Transfer-Encoding: 7bit Message-Id: <16150.64064.818226.448155@altair.dfrc.nasa.gov> Date: Thu, 17 Jul 2003 12:34:24 -0700 To: sc22wg5@dkuug.dk Subject: 4 Dresden papers X-Mailer: VM 7.07 under 21.4 (patch 12) "Portable Code" XEmacs Lucid Sender: owner-sc22wg5@dkuug.dk Precedence: bulk --V0NHczuRvJ Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit In reviewing the files on the WG5 server, I was reminded that I haven't sent in the final versions of N1539, N1540, and N1543. They are attached below. These are the same as the drafts I sent out in email about a month ago, except for the title line (which no longer says DRAFT). I've also attached an as-yet unnumbered paper intended to supercede N1527 (typos and editorial trivial). Part III of that paper has a technical question that might merit WG5 input; I half expect the rest to be just forwarded to J3, but since N1527 was a WG5 paper, it seemed like its update should be also (so that WG5 wasn't looking at something that had already been updated). --V0NHczuRvJ Content-Type: text/plain Content-Description: N1539.txt Content-Disposition: inline; filename="N1539.txt" Content-Transfer-Encoding: 7bit ISO/IEC JTC1/SC22/WG5 N1539 Storage size Richard Maine This is a revision of N1531 based on comments about it. This paper proposes that we replace NUMERIC_STORAGE_SIZE and CHARACTER_STORAGE_SIZE with an intrinsic function that can inquire about the size of any storage unit defined by the standard. I. Why do anything? In response to a public comment, paper J3/03-108r3 added three new named constants to ISO_FORTRAN_ENV. I have no objection to the addition of FILE_STORAGE_SIZE. However, for the other two, I strongly feel that this is something that we should do correctly if we are going to do it at all. Many, if not most, implementations already have a similar function. I have avoided the most common current names for it specifically to avoid potential conflicts in points of detail .... and that allows me to do one thing in what I consider to be a more robust way (we will return the size in bits instead of in octets). With NUMERIC_STORAGE_SIZE and CHARACTER_STORAGE_SIZE we would be adding a new feature that not only is obsolete now - it was obsolete two revisions of the standard ago. Those constants constants would have been adequate for f77. As of f90, they are woefuly inadequate. Why are we adding new features to f2k that support only f77 code and are all but useless for code that follows most style recommendations for f90 code? Are we prepared to explain our answer to that question when it gets asked by users, as it most certainly will be? When that happens, don't expect me to defend the feature. I do not find the argument that "this is what someone asked for" to be very convincing. People ask for lots of things that they don't get. We need to apply our best judgement in answering requests - not just limit the answers to yes or no. In this case, a solution that I consider good is quite doable. We can do the job in a way that provides both the requested functionality and also useful for newer coding styles. It isn't particularly difficult to do that. If we don't think this feature is worth the small amount of work to do that way, or if a majority thinks that it is harder than I do, then I don't think we should do it at all. II. Design considerations and alternatives This function could be added either as an intrinsic or as a module procedure in ISO_FORTRAN_ENV. I came down slightly on the side of doing it as an intrinsic, but it was a close call. The edits below are for that approach. If a majority finds it more appropriate in the module, that is an easy change and one I'd find acceptable. Other choices for the function name would also be acceptable. The proposed function allows array arguments, but always returns the size of a scalar of the type. The standard adequately defines the storage requirements for arrays in terms of those for scalars, so I see no need for array-related functionality in this function. I consider the proposed function similar to the LEN intrinsic in this regard (LEN accepts array arguments, but returns the length of an element rather than the length of the whole array). The edits below delete the NUMERIC_STORAGE_SIZE and CHARACTER_STORAGE_SIZE constants, because the function is more general. If one wanted to have both the constants and the function, I wouldn't object too strongly. That wouldn't be my first choice, but it is well within bounds that I'd consider reasonable as a compromise. The allowable types of the argument are restricted to those types for which the standard already defines a storage size concept; this is all types that can be involved in storage association. In addition to the restrictions below, Van also suggested disallowing derived types with length type parameters (we do want to allow character though, so it would be important that this restriction be only on derived types). It appears to me that the draft already defines a storage unit for derived types with length type parameters and that therefore such a restriction is unnecessary here. It is possible that this is an error in the existing draft; if so, and if that is corrected, then I'd agree that such a restriction is appropriate here. I think the real question there is whether the existing draft is acceptable in defining such storage units. That is not fundamentally a question about this intrinsic; the intrinsic should just inquire about whatever the rest of the draft defines. It appears to me that the existing draft is in error in that it disallows BIND(C) types in storage association contexts. I believe that to be an unintentional oversight based on thinking that BIND(C) is a form of SEQUENCE. I think it quite important to be able to inquire about the size of BIND(C) types, so I have allowed them here, in anticipation of this oversight in the existing draft being fixed. If the committee truly believes that BIND(C) types should not be allowed in storage association contexts, then the "or have the BIND attribute" in the edits below should be deleted (but I really think that would be a mistake). For simplicity, this proposal depends on the declared type instead of the dynamic type. It turns out that the other restrictions rule out all the cases where there can be a difference, so this could be written either way (and could be changed in the future without incompatibilities). I'm willing to go either way on that. If this is changed to allow polymorphic arguments (in which case there could be a difference), we should still disallow unlimitted polymorphic arguments (becase they would need additional restrictions to make them work). I think the KIND argument unnecessary, but it was suggested and I go along with adding it for consistency. I'd also go along with deleting it. III. Edits [127:41+] Add list item (4a) the inquiry function STORAGE_SIZE, [298:19+] Add line "STORAGE_SIZE (X [, KIND]) Storage size in bits" [356:1+] Add section 13.7.115a STORAGE_SIZE (X [, KIND]) Description. Returns the storage size in bits for a nonpointer nonallocatable scalar of the declared type of X. Class. Inquiry function. Arguments. X may be of intrinsic or derived type. It shall not be polymorphic. If it is of derived type, that type shall be a SEQUENCE or interoperable type and shall have no allocatable ultimate components. If its type has any deferred type parameters, it shall be a pointer that is associated or an allocatable object that is allocated. It may be a scalar or an array. KIND (optional) shall be a scalar integer initialization expression. Result Characteristics. Integer scalar. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of default integer type. Result Value. The result value is the size in bits of the storage unit (16.4.3.1) in a storage association context for a nonpointer nonallocatable scalar with the declared type and type parameters of X. Example. STORAGE_SIZE(1.0) returns the number of bits in the numeric storage unit. [417:36-38] "The sizes...(13.8.2.3)" -> "The size of the file storage unit is given by the constant FILE_STORAGE_SIZE (13.8.2.3.3). The sizes of the character storage unit, numeric storage unit, and unspecified storage units can be determined using the intrinsic function STORAGE_SIZE (13.7.115a)." [362:28-33] Delete sections 13.8.2.3.1 and 13.8.2.3.2. {This assumes that 13.8.2 has been simplified as described in part 1 of my paper titled ISO_FORTRAN_ENV. If that isn't done, then other trivial changes are needed in the sentence that forms the body of 13.8.2.3, and the 13.8.2.3.3 section heading should probably be deleted (or promoted). --V0NHczuRvJ Content-Type: text/plain Content-Description: N1540.txt Content-Disposition: inline; filename="N1540.txt" Content-Transfer-Encoding: 7bit ISO/IEC JTC1/SC22/WG5 N1540 Type-spec Richard Maine The examples in 8.1.5.3 do not agree with the bnf for the select type construct. The examples have statements like CLASS IS (POINT) TYPE IS (POINT_3D) According to the bnf, these should be CLASS IS (TYPE(POINT)) TYPE IS (TYPE(POINT_3D)) This paper proposes that the bnf be fixed to correctly reflect the syntax shown in the examples. It also proposes to correspondingly change the bnf syntax for explicitly typed array constructors and explicitly typed allocate statements. I. Why this change instead of some other? I believe that the examples, rather than the bnf, reflect what was the intent of the committee. The bnf version sounds wordy and either redundant (type is type) or contradictory (class is type). I believe that a lot more people studied the syntax of the examples than traced through the syntax of the bnf (if they had really traced through the bnf syntax, I'd have expected them to notice that the examples didn't agree with it). As additional evidence, I note that papers like N1522 (and all its predecessors) use syntax like that of the examples instead of following the bnf. Note also, that the current bnf is new to the 03-007. The CD did not require the TYPE() bit of syntax. The bnf of SELECT TYPE was redone in the 03-007, apparently without this aspect of the difference being noticed. If it was noticed, the difference was not made sufficiently clear that anyone noticed that it made the examples incorrect. Thus this paper is proposing to fix a mistake introduced in the 03-007 rather than to change a long-established syntax. Once we introduce this syntax into the bnf, I believe it is both simpler and more consistent to use it in two other places that currently derive from the same bnf, but could just as well use the simpler form. Those places are explicitly typed allocate statements and explicity typed array constructors. These places are all new to f2k, so there are no compatibility issues. The draft has no examples of explicit typing for allocate statements or array constructors. (Perhaps it should, but that's a separate question.) The only place where we need the long-winded form that includes TYPE() is in , which is a different branch of the syntax tree for other reasons anyway. II. Important f90/f95 interp question I think that C414 was intended to also exclude the name doubleprecision. Otherwise I'm not sure what it achieves. If doubleprecision is allowed as a derived type name, then the syntax of the examples has an ambiguity (intrinsic keywords do not "go away" when there is some other entity with the same name). The edits below include what I think is a clarification of this. If people think this is a change instead of a clarification, then we'd probably need to list that as an f90/f95 incompatibility. III. Incorporated editorial improvement Introducing this syntax into the bnf facilitates an overdue minor organizational improvement. We can cleanly separate the bnf for type specification from that of object declaration. Currently, it is a bit odd that the syntax for a type specification is mixed in with the section on object declaration, even though parts of it have nothing to do with object declaration. We will move the bnf for type specification into...surprise... the section talking about types. The fact that this eliminates a bunch of forward references from chapter 4 into chapter 5 gives an extra hint that this is where it belonged all along. This also eliminates a much duplication between 4.5 and 5.1.1. This move isn't required. We could keep all the bnf where it currently is in chapter 5, but I think this an editorial improvement. If a majority thinks otherwise, that question is separarable (but my proposed edits would need revision). IV. Edits [33:8+] Insert A type is specified in several contexts by a <>. R400a <> <> C400a (R400a) The shall not specify an abstract type (4.5.6). {Seems like a good place for this - right after we've introduced intrinsic and derived types, and before any of what used to be forward references to this concept. This first edit is the one where the syntax change in the definition of is.} [34:15] "5.1" -> "4.4" {We are moving that material} [35:27+] Delete [69:16-22] (R503) and move all but the last line of it to here as R401a, renaming it to . Move [70:21] (R507) to here as R401b. Move [71:20-21] (C526) to here, changing (R503) to (R401a) {This would probably be better referencing 401b instead of 401a, but I'll leave that aspect as is to minimize the number of changes to question.} [36:7], [38:1,2], [39:10], [40:15], [42:23] "(R503)" -> "(R401a)" (6 times) [43:10-11] Delete this para. {No longer says anything useful.} [36:8-9], [38:4,5], [39:13], [40:16-17], [42:24-25] "the data entity is of type" -> "the type specified is" (6x) {The phrase "the data entity" in several places is confusing. We aren't necessarily talking about any particular data entity, or multiple ones might be relevant, depending on context. In this section we are just talking about what type is specified, so we'll say that. The relationship of types to entities is discussed elsewhere and is just a confusing irrelevancy here. The above edit is not mandatory; it is a separable question.} [38:6] After "(0.0D0)." insert "The type specified by REAL(KIND(0.0D0)) is the same as the one specified by DOUBLE PRECISION." {Replacement for material that will be deleted from chapter 5.} [40:14+] Insert heading "4.4.4.0a Character type specifier" [40:17+] Move [74:1]-[75:2] to here, after changing the "" at [74:30] to "". {Much of the [74:30-35] para is about , which our new definition of excludes; this change gets both cases, as we need it to.} [40:17++] Move Note 5.5 (pg 75) to here, changing "declaration statements" -> "specifiers" and deleting the s ("A" in the first example, "B, C*20" in the second). [40:17+++] Insert heading "4.4.4.0b Character literal constant" {Character declarations are messier than the other intrinsic type declarations. It takes a substantial subclause in chapter 5 to give all its details. The above edits mostly just copy that subclause to chapter 4. It has enough references to things all over the document that it fits about as well (or poorly) either place, but once we move the other stuff, this would look pretty lonely in chapter 5.} [44:2] Before 'the same' add 'DOUBLEPRECISION or'. [69:9] replace line with "R502 <> <> TYPE() {Handle the cases where we need the TYPE().} [69:Note 5.2] before "or" insert ", a SELECT TYPE statement," {Notes should be helpful instead of misleadingly incomplete.} [69:23] "(R503) The " -> "(R502) The TYPE()" {Previous edits removed R503 from here. For C503 to still apply to all the same cases, we basically need 2 copies of it (or one copy that refers to 2 bnf rules). One copy was added above as C400a. The other copy stays here with some changes. Another paper makes the 4.5.3 xref more sensible.} [73:3] "Type specifiers" -> "Declaration type specifiers" [73:4] "<>" -> "" [73:7]-[75:8] Delete sections 5.1.1.1 to 5.1.1.6, replacing them with the sentence "An in a type declaration statement is used to declare entities of intrinsic type." {Much of 5.1.1.1 to 5.1.1.6 already duplicated material in chapter 4. The parts that weren't already in chapter 4 have been added above.} [75:11-15] Delete this para. {The parts of [75:11-15] that make any sense are already in 4.5. The "If the contains a " part makes no sense because the isn't optional.} {There are no edits needed in chapter 8; the above edits make be the right thing.} --V0NHczuRvJ Content-Type: text/plain Content-Description: N1543.txt Content-Disposition: inline; filename="N1543.txt" Content-Transfer-Encoding: 7bit ISO/IEC JTC1/SC22/WG5 N1543 ISO_FORTRAN_ENV Richard Maine This is a revision of N1529. Three of the new intrinsic functions addded at the previous J3/WG5 meeting are, in my opinion, more appropriate in the ISO_FORTRAN_ENV module than as intrinsics. This paper addresses that and some issues that came up while looking at that. The four parts of this paper are more or less independent. Any combination of the four parts could plausibly be passed with at most minor adjustments in the other parts. I. Simplify organization of 13.8.2 The 13.8.2.x subheadings don't add much in my opinion; I think them of negative value. They just make the important stuff harder to find. They don't stand out well from the next level of subheadings under them. Indeed, because of the capitalization conventions, the 13.8.2.x.x subheadings look more prominent than the 13.8.2.x ones. The text in the 13.8.2.x.0 sections is mostly fluff and wouldn't be missed; only the xrefs from it seem worth keeping. Therefore: EDITS: [361:29-31] Delete subsection 13.8.2.1, including its heading and body, but not including the subsections below it. [362:3,7,11] Before "." insert " (9.4)". (3 times) [362:13-15] Delete subsection 13.8.2.2, including its heading and body, but not including the subsections below it. [362:18,22] After "specifier" insert " (9.10.4)". (twice) [362:25-27] Delete subsection 13.8.2.3, including its heading and body, but not including the subsections below it. [362:1-363:3] Alphabetize and appropriately renumber all the 13.8.2.x.x subsections. [361:28+] Insert the following, depending on whether or not parts 2 and/or 3 of this paper pass. If part 2 or 3 of this paper passes, then insert a section heading "13.8.2.1 Named constants in the module" If neither part 2 nor 3 passes, do not insert the heading because we should not have a 13.8.2.1 without a 13.8.2.2. (That's an ISO guideline that we don't follow as consistently as we should.) Instead, promote all the 13.8.2.x.x subsections up one level. In either case, insert the following para, either as the sole para of 13.8.2.1 or as an additional para of 13.8.2. "The processor shall provide the named contants described in the following subclauses." II. Move the new functions. The IS_IOSTAT_END and IS_IOSTAT_EOR functions seem quite appropriate for ISO_FORTRAN_ENV. They concern system-dependent aspects of the Fortran I/O environment. Indeed, they are so closely tied to the IOSTAT_END and IOSTAT_EOR constants that I can't figure out any good justification for them not to be in the same module as the constants. The only "justification" I can think of is one that I wouldn't classify as good: if someone thinks that we shouldn't have procedures in intrinsic modules, then they are a bit late for that objection - we'd have to substantially redo the IEEE_* and ISO_C_BINDING modules. The NEW_LINE function also inquires about a system-dependent aspect of the Fortran I/O environment, fitting well with the other things in ISO_FORTRAN_ENV. EDITS: [235:2] "intrinsic" -> "module" [363:3+] Insert new subsection (it will be either 13.8.2.2 or 13.8.2.4, depending on whether or not part 1 passes) "13.8.2.x Procedures in the module The processor shall provide the module procedures described in the following subclauses." [327:2-15] Move these (13.8.7.57-58) into the new 13.8.2.x in alphabetic order. [341:14-26] Move this (13.8.7.85) into the new 13.8.2.x in alphabetic order. [394:Note 15.3] The xref for NEW_LINE will automatically renumber. [298:17] Delete line for NEW_LINE [300:10-11] Delete lines for IS_IOSTAT_END and IS_IOSTAT_EOR. III. Move other procedures This also seems like an appropriate time to review whether COMMAND_ARGUMENT_COUNT, GET_COMMAND, GET_COMMAND_ARGUMENT, and GET_ENVIRONMENT also belong in ISO_FORTRAN_ENV. I think they do, but I probably suggested that before and failed to generate enough support to make it happen. However, the decision might well be different when looking at the standard as an integrated (well, as much as we can) whole than it was when looking at the individual procedures. I'm not sure that we ever stepped back and looked at that larger picture of integration. Can anyone look at a procedure named GET_ENVIRONMENT_VARIABLE and fail to wonder why it isn't in the module named ISO_FORTRAN_ENV? Note that putting these procedures in the module would not invalidate any existing early implementations that might already provide them as intrinsics; it would still be valid for an implementation to have them both ways, with the intrinsic procedure version as a processor-defined intrinsic. One widely used existing implementation (f2kcli) already does these procedures in a module. In the abstract, I'd also think that module a good place for CPU_TIME, DATE_AND_TIME, and SYSTEM_CLOCK, but it doesn't seem worth either the incompatibility with f90/f95 or the complication of doing them both ways, so I don't propose that. EDITS: [300:4,6.5-9] Delete the lines for COMMAND_ARGUMENT_COUNT, GET_COMMAND, GET_COMMAND_ARGUMENT, and GET_ENVIRONMENT_VARIABLE. [310:17] This xref will auto-renumber. [363:3+] If part 2 didn't pass, we need to do the [363:3+] edit from it anyway for part 4. [310:8-17] Move this (13.8.7.21) into the new 13.8.2.x in alphabetic order. [319:6-321:4] Move these (13.8.7.41-43) into the new 13.8.2.x in alphabetic order. [486:28] "intrinsic" -> "module" IV. Other trivial fixups to the new functions I recommend the following minor editorial fixups to the descriptions of the IS_IOSTAT_END, IS_IOSTAT_EOR, and NEW_LINE functions, whether they move into the module or not. [300:10-11] "condition" -> "value" (twice) {If part 2 passes, the above edit is moot. If part 2 does not pass, these lines should be made correct. These functions do not, in fact, test for an end-of-file or end-of-record contition. They test an integer value, which might or might not have come from an IOSTAT= specifier. You could get a true result from these functions without any I/O ever having been done.} [327:3,10] "the argument" -> "a" {Wording simplification.} [327:8,15] Change both xrefs to 9.10.4, which is the section on IOSTAT=. {Sections 9.10.2 and 9.10.3 on END= and ERR= are only peripherally related, and indeed actually in turn reference 9.10.4 for the appropriate material.} [327:7-8,14-15] "that would be assigned to" -> "for", and "to indicate" -> "that would indicate" (twice) {To me, the wording of the result value clauses almost make it sound like the programmer could cause a condition to be signaled by setting the variable to these values.} [341:24] "The" -> "Otherwise, the" {As is, case 3 is interp bait. Does it imply "or", "and", or "otherwise"? It makes a difference. Let's say now instead of in the interp answer.} [341:25] "one" -> "such a character" {One what? File connected for formatted stream output?} [235:Note 10.17] Replace note body with "If the module function NEW_LINE returns a blank character for a particular character kind, then the processor does not support using a character of that kind to cause record splitting in a formatted stream file." {If we want to have Note 10.17 at all, it would be good for it to make sense. I don't know what field it is talking about splitting; I think it means record splitting. And I'm not sure whether the statement otherwise is a tautology or a contradiction. In one sense, if the processor actually supports the newline character as something that could be written as part of the data in a record, that would be the case where the newline character could *NOT* be used to split records, making the statement a contradiction. In another sense, it is a tautology that you aren't allowed to do something (write the character), then you aren't going to be able to split records by doing it. Let's just say what we mean; it isn't very complicated - either that or is is so complicated that I don't yet understand it.} [127:41+] Add list item (Adjust xref as appropriate.) (4a) the inquiry function NEW_LINE (13.8.2.2.3), {I'd think people likely to want to use NEW_LINE in initialization expressions. I see no reason to prohibit this.} [235:3] After NEW_LINE add " (13.8.2.2.3)". {An xref here seems like a good idea. Adjust as appropriate.} --V0NHczuRvJ Content-Type: text/plain Content-Description: typos.txt Content-Disposition: inline; filename="typos.txt" Content-Transfer-Encoding: 7bit ISO/IEC JTC1/SC22/WG5 N???? Typos and editorial trivia in 03-007 Richard Maine This is a revision of N1527. It adds more material and was reorganized. This paper has edits to correct some typos and editorial trivia in 03-007. All page and line references are to 03-007. I. Typos and errors Thanks to Aleksander Donev, Dick Hendrickson, Bill Long, Van Snyder, Craig Dedo, and James Giles for pointing out most of these; for the most part all I did was collect them. [44:19] "accessibile" -> "accessible" [4:23] "USE" -> "use" [47:Note 4.24 2nd line] "to to" -> "to" [47:16] "sitype-param-decl" -> "" [55:10] "" -> "" [59:Note 4.51] Reformat the example as TYPE, ABSTRACT :: FILE_HANDLE CONTAINS PROCEDURE(OPEN_FILE), DEFERRED, PASS(HANDLE) :: OPEN ... END TYPE [62:15] !derived-type-spec? -> [69:23] "4.5.3" -> "4.5.6" {I thought some other paper was going to fix this, but I don't see it anywhere.} [74:24] "declaration-type-spec" -> "" [164:23] "paraqmeter" -> "parameter" [164:16,17,21] Use "\si{type-spec}" instead of "\sinr{type-spec}" in the LaTeX source, which won't cause any obvious difference here, but will eliminate the duplicate entry for in the index. [268:Note 12.15] "C_LOC" -> "C_FUNLOC" (twice) [299:29] "allocatiom" -> "allocation" [308:8] "=\pi" -> "-\pi" (where \pi means the math symbol). [327:3,10] "and" -> "an" (twice) [335:26] "upside-down !" -> "<" [337:1] "<" -> "<=" (like in MAXLOC) {That's a less-than-or-equals sign, \leq in LaTeX-speak}. [340:Note 13.15 2nd line] "transfering" -> "transferring" [357:8] Delete 1 of the 2 minus signs. [357:8] "86339" -> "1573039" [418:6] Delete spurious blank after "unit". [434:37] Alphabetize "parent type" correctly; move to (435:2+] [444:37] "Data extension" -> "Type extension" {The term "data extension" is used nowhere else} [445:36] Indent this line like the REAL declarations earlier. [446:7] Delete "! Not shown here" {Lines 12-16 do appear to show it. If the "here" is supposed to exclude those lines, that is unobvious and misleading.} [449:12] The wrong style of dash was typeset, but instead of just changing the dash, a better edit is "-so" -> ";". II. Editorial suggestions A. Nondelimited/undelimited Section 10 has 3 cases of "nondelimited" and 1 of "undelimited". I agree with Dick that "undelimited" sounds better, so I propose changing "[a] nondelimited" to "[an] undelimited" at [240:21], [241:6], [243:3], and [248:4]. Alternatively, we could change "undelimited" to "nondelimited" at [246:Note 10.35 3rd line]. Don't do both edits. (If this paper passes without directions to the contrary, do the 4 changes instead of the alternative one.) B. Since The word "since" is best reserved for contexts where it refers to time. Some of the uses in the draft are appropriate, but others are not. In some cases, it is potentially confusing because time is involved in the sentence, but that isn't what the "since" is referring to. "since" -> "because" (retaining capitalization) at [8:34], [12:Note 2.2], [45:Note 4.21 line 6] [49:Note 4.27], [277:Note 12.31], [347:21], [368:20], [414:Note 16.10 line 19], [440:38], [465:25] "since" -> "in that" at [441:7] (Both "since" and "because" seem wrong here). C. Redundancy in constraint wording. Several of the constraints have redundancies like "(R612) In a ...", where R612 is the definition of . The R612 part *MEANS* "In a ", so this is completely redundant. We don't consistently have this redundancy. Nor do I think these are special cases that merit the redundancy for emphasis. I think these are just holdovers from when the (R612) syntax was added; that addition was done en mass, without any wording changes. The following may not be all the cases, but since we are already inconsistent, so I don't consider the likelihood that this misses some to be a reason not to do it (though if more are noticed, fixing them would also be ok). Delete "In a ," and capitalize the next word at [205:3] (C609), [105:4] (C610), and [105:13] (C614). Delete "In a ," and capitalize the next word at [105:24] (C615), Delete "In an ," and capitalize the next word at [107:11] (C617). Delete "In an ," and capitalize the next word at [107:14] (C618). The following cases have slightly different form and thus need a slight additional wording change. [105:9] (C613) "In a containing" -> "If there is" [107:17] (C619) "In an with" -> "If there is" D. Misleading bnf term N1524 points out that the bnf term causes confusion because we use the Engish word "binding" to mean something different. For example, the use of "binding" at [56:10] does not mean the bnf defined 3 lines earlier, but instead means a , , or , as defined in R444. Although those three things are kinds of bindings, they are not kinds of ; instead a is a syntactic part of a . This is horribly confused. I originally suggested using a different bnf term (possibly would do), but on further study, we don't appear to need a bnf term for this at all. I speculate that the existing bnf term might be a remnant of some earlier syntax. In any case, it trivially factors out of the current syntax without loosing anything except the confusion. [56:7] (R448) Delete the bnf definition of . [55:8,9,10,11(twice)] Change all other occurances of to . (Yes, I verified with grep that these 5 are the only occurances). [56:8-9] Move C462 to [55:10+], renumbering the constraints and changing its (R448) reference to (R445). III. More significant error This possibly should be in a separate paper, as it goes beyond the typographical or editorial level, but I hated to write yet another separate paper. Although this has technical content in changing what is legal, this *HAS* to have been an unintentional oversight...doesn't it? Did we really want to disallow interoperable derived types in COMMON? Even in COMMON with the BIND(C) attribute? I'm assuming that someone just thought that BIND(C) was a specific form of sequence type. (Although I think that would be a fine way to define them, we didn't do so); or perhaps this was overlooked completely. As is, when combined with C561, this disallows all derived types in BIND(C) COMMON blocks. I understand why C597 disallows variables with the BIND attribute, but variables of BIND(C) types, as disallowed by C598 are a different matter. [98:20] "with" -> "or a type with the BIND atribute and it shall have" I'm also not sure whether the similar prohibition against equivalence of BND(C) types is intentional, but that seems less glaringly wrong to me, so I left it alone. --V0NHczuRvJ Content-Type: text/plain; charset=us-ascii Content-Description: .signature Content-Transfer-Encoding: 7bit -- Richard Maine | Good judgment comes from experience; Richard.Maine@nasa.gov | experience comes from bad judgment. | -- Mark Twain --V0NHczuRvJ--