J3/01-214r1 Date: 7th June 2001 To: J3 From: Malcolm Cohen Subject: Further "name" infelicities 1. Introduction Further infelicities have been committed through the agency of the implicit "xyz-name is name" rule. This paper addresses these problems. Additional explicit "name" rules are proposed. 2. Problems (a) "scalar-int-constant-name" is used for R406 with no further constraint, thus allowing kind parameters to be variables or indeed procedures! I propose adding a constraint. (b) "dummy-arg-name" is widely used and nowhere specified to be the name of a dummy argument, though sometimes one can deduce it from the surrounding text, if only because it makes little sense otherwise. (But not always: the VALUE statement says only that it specifies the VALUE attribute for a list of objects, not a list of dummy arguments; we should fix this too, because the wording differs from that of INTENT and OPTIONAL for no good reason.) I propose defining a syntax term "", constrained to be the name of a dummy argument. This should work everywhere it is needed, and will be harmless for the and since that appearance defines it to be a dummy arg. (c) "namelist-group-name" is used in chapter 9 without any indication that it is meant to be the name of a namelist group (other than the suggestive naming of the syntax term). I propose adding a constraint. (d) "scalar-variable-name" is used once only, for character substrings, and with no constraint at all. This produces ambiguous BNF, since also includes names. There are two plausible fixes here: (1) change "scalar-variable-name" to "scalar-object-name", and change "scalar-constant" to "scalar-literal-constant"; or (2) define a syntax term "variable-name" that is constrained to be the name of a variable. Since (e) proposes the latter, the latter will do. (e) "variable-name" is used all over the shop with no constraint. We should define the term with constraint, and check that all existing uses of "variable-name" actually mean what they imply! (f) Variable definition context has the wrong syntax term for the elements of a NULLIFY statement. (g) "procedure-name" is used in several places, two of which (pointer assignment and actual arguments) appear to have inadequate constraints. Pointer assignment should probably be completely rewritten anyway; I'll leave that to another paper. A revised constraint is proposed for actual arguments. (h) "type-alias-name" is used with no constraint in R503. I'll propose putting one in. Strangely enough, we don't have anything called a "type alias" - 4.6 only gives us "type alias name"s; that would be fine except that the rest of the standard thinks that we have type aliases. Two possible fixes: change the rest of the standard to use "type alias name", or change 4.6 to define type alias. I'll attempt the latter, since the former would involve changing fairly readable things like "type alias for an integer type" into "type alias name that is an alias for an integer type". Not to mention the potential confusion trying to describe the scoping rules. Type aliases are also missing from the (non-normative) definition of "entity", though the scoping rules make it clear that we think they are entities. I'll add it (though now I look at it, there are other things missing from the "entity" definition as well - they'll have to wait until later). 3. Edits to 01-007r1 [34:9+] Insert new constraint "Constraint: A shall be a named constant of type integer." [59:34-36] Replace "A ... particular type" with "A <> is an entity that may be used to declare entities of an existing data type; it is not a new data type." {OK, this is a bit clumsy-sounding, but at least we are defining the term used elsewhere in the standard. The sentences being replaced are not exactly deathless prose either.} [59:36] Replace "A type alias name that is an alias for" with "The name of a type alias for". {Improve wording, now that 4.6 can use the term "type alias".} [65:34] Insert constraint "Constraint: A shall be the name of a type alias." {Necessary constraint.} [87:1] Change "objects" to "dummy arguments". {Make it parallel to INTENT and OPTIONAL, and more similar to the VALUE attribute.} [89:38] Move to [89:42+] {The three constraints apply to the previous syntax rule, not this one.} [97:8+] Insert "R601a <> Constraint: A shall be the name of a variable." {Just after the definition of , though it is referenced already around [89:43-].} [108:9+] Insert "<> " {Now that means what it says, we need to allow procedure pointers explicitly. The bnf term is introduced by 01-213. has no constraint on it, so already includes procedure pointers; this is not necessarily a good thing, but will do for now.} [180:38+] Insert new constraint "Constraint: A shall be the name of a namelist group." [255:27-29] Replace negative constraint with positive one: "Constraint: A shall be the name of an external procedure, a dummy procedure, a module procedure, or a specific intrinsic function that is listed in 13.10 and not marked with a bullet(.)." Note to editor: (1) insert bullet symbol appropriately. (2) do not make the typo "market" for "marked". {Note to J3: we do not need to say anything about generic names - we've already excluded them except where it is (also) the name of an external/module proc.} {Further note: I've carefully used the wording "specific intrinsic function..." to handle (a) the case where a user proc/variable has a name listed in 13.10 and (b) the potential name-remapping via USE. We most certainly do not want to claim that the name itself has to be one listed in 13.10 etc.} [255:37-39] Delete unnecessarily clumsily worded constraint. {We've absorbed it into the improved one above.} [265:41+] Insert new rule and constraint "R1225a <> Constraint: A shall be the name of a dummy argument." {This is perhaps the most obvious place to put the definition of dummy-arg- name, though it is first used near [84:31].} [350:33+] Insert new list item "(6+) A in a in a ;" [361:44} Delete "or ". [361:45] Before "," insert "or ". {Nullify statement added to wrong list item!} [362:1] Fix typo "" -> "". [401:8] After "construct" insert ", type alias". {Add type alias to the definition of "entity".} ===END