From maine@altair.dfrc.nasa.gov Thu Jan 18 00:33:44 1996 Received: from altair.dfrc.nasa.gov (altair.dfrc.nasa.gov [130.134.34.72]) by dkuug.dk (8.6.12/8.6.12) with SMTP id AAA25054 for ; Thu, 18 Jan 1996 00:33:40 +0100 Received: by altair.dfrc.nasa.gov (5.0/SMI-SVR4) id AA08032; Wed, 17 Jan 1996 14:02:37 +0800 Date: Wed, 17 Jan 1996 14:02:37 +0800 Message-Id: <9601172202.AA08032@altair.dfrc.nasa.gov> From: Richard Maine To: SC22WG5@dkuug.dk In-Reply-To: <199601170808.JAA01071@dkuug.dk> ("Erik W. Kruyt (+31 71 5276804)"@dkuug.dk) Subject: Re: (SC22WG5.998) Suggested edits to X3J3/95-007R2 content-length: 0 The following are my comments about Erik Kruyt's suggested edits to X3J3/95-007R2. > 1. place END DO in index Same response as to several other reasonable suggestions about adding new index entries. Although good suggestions, it would be a lot of work to add all of them, particularly those without more specific citation details. WG5 did not direct that these be done. > 2. The list on page 25 with keywords with optional blanks consists of all > keywords with can be split into two or more complete English words. > While INOUT is in the table READWRITE is not. I suggest to add READ WRITE to > the list. I disagree that READWRITE is in the same category. Unless I forget a place (which is possible), READWRITE is not a keyword. It is used only in a character context, whereas the keywords are all used outside of character contexts. Note also that readwrite is in general interpreted at run time rather than at compile time. In any case, although it might be reasonable to allow blanks in READWRITE, this would be a technical change, not just an editorial matter. I cannot incorporate a technical change of this nature without instruction from WG5. In my opinion, such a change for f95 would not be appropriate. This is, of course, WG5's decision to make. I plan to do nothing on this unless I get instructions otherwise from WG5. > 3. The table on page 25 lists keywords with optional blanks. > Throughout the document most of these keywords are used with the > optional blanks, but not for ENDFILE, INOUT and, if added, > READWRITE. I suggest to insert the optional blank in all occurrences > of these keywords to be consistent. Although this is a reasonable editorial suggestion, the benefits seem to small to justify doing it now in my opinion. This is not just a simple global change because several of the instances are in sample code where column alignment would need to be adjusted to compensate for the extra blank. Although each case would be easy enough, there are probably enough cases to make substantial likelihood of messing up at least one. Although it would not be a major catastrophe to have misaligned columns in one or two examples, I also don't think the usage of ENDFILE and INOUT without blanks is a big problem (actually, it matches my personal style - well, the INOUT anyway - I scarecely ever use ENDFILE). I'd propose no change here unless directed otherwise. > 4. 5.1.2.4, page 54, line 2: > "The rank or the rank and shape" > Shape, however, specifies rank and extents, so the text should read: > "The rank or the shape". Agree. Added to my list of proposed changes. Also change the following "are" to "is" to agree in number. > 5. 5.1.2.x > In the description of some of the attributes (EXTERNAL, INTRINSIC) > there is a sentence: > "This attribute may also be declared via the ... statement", or similar > wording (DIMENSION) but not for others (PARAMETER, accessibility, INTENT, > SAVE, OPTIONAL, TARGET, ALLOCATABLE). This is confusing. Please include > this sentence in the description of each of the attributes. > In 5.2 take out the sentence "This also applies to EXTERNAL and INTRINSIC > statements." because it suggests that this is a special case. I'd propose no change here. I agree that there are several stylistic inconsistencies in this area. In fact, I think it could use a pretty major rewrite (but not for f95). My preference would be to clearly separate semantics and syntax, describing the various attributes, their interactions and meanings in a section completely divorced from the syntactic details of how to specify the attributes. There are lots of cases of restrictions refering to syntax (as in saying that something appears in a SAVE statement) where I think it would be simpler (and less prone to error) if they referred to semantics (as in something has the SAVE attribute). However, this would be a substantial rewrite that I think is inappropriate at this stage (and if I proposed it, I'm quite confident that I would be overruled). There is actually some logic to the apparent inconsistencies that Kruyt notices. This is not to say that the logic is necessarily good enough to justify the inconsistencies, but they are not completely random. I could well imagine some people objecting to the changes for one or more of the following reasons. Therefore, since there is nothing actually incorrect here, I'd currently propose no change for f95. EXTERNAL and INTRINSIC are special in a way. Specifically, they are described in section 12 instead of 5.2. Section 5.2 is titled "Attribute Specification Statements". Although EXTERNAL and INTRINSIC seem a lot like attribute specification statements, I'm not entirely sure that the standard specifically says that they are (though I skimmed pretty quickly and could have missed it). Thus it is not entirely redundant to say that something about attribute specification statements also applies to INTRINSIC and EXTERNAL. One might plausibly argue that INTRINSIC and EXTERNAL should be moved from section 12 into 5.2, but there are certainly other people who would argue against it. Such a move would be too major a change for me to adopt without specific direction. DIMENSION is also special because it can be specified in so many places. Not only can it be in a type specification statement (in 2 different places) or in a DIMENSION statement, it can also be "strange" places like in a COMMON statement and the other places listed in the section on the DIMENSION attribute. Whereas the existing apparent inconsistencies could be confusing, the proposed change could be confusing in other ways. (I can already imagine the resulting interpretation request asking whether INTRINSIC and EXTERNAL are attribute specification statements). Thus, I'd propose no change for now unless I'm directed otherwise. -- Richard Maine maine@altair.dfrc.nasa.gov