J3/99-148r2 Date: 27th May 1999 To: J3 From: Malcolm Cohen Subject: Unresolved issue 16 1. Introduction Issue 16 raises several problems with the PROCEDURE-declaration statement: (1) "Need ... necessary agreement between the characteristics specified here and those of the external procedures..." IMO this is provided by [87:32-33], though the wording is not very clear. (2) [269:12-19] "makes no sense for dummy procedures and abstract interfaces" This text is unchanged from F90, F90 had dummy procedures, no-one has asked us what it means, therefore maybe this is not a really a serious problem (or maybe an interp should be raised?) (if the characteristics don't match) "The problem would be in the procedure statement". Actually, either way of describing it is ok, because the standard only blesses programs as a whole, not parts thereof (ref lots of email/postings from JGiles where he bemoans this). However, I do take Richard's point that the wording is at the very least confusing - thus my proposed edits below. Actually I think there is another problem: section 5.2 is completely misplaced. It refers to lots of things that are only described in chapter 12, which would perhaps not be a fatal flaw if the INTRINSIC and EXTERNAL statements had been described in chapter 5 as well! Since PROCEDURE is basically a souped-up EXTERNAL statement, splitting them like this is bad, very bad. (3) Specification (not syntax as far as I can tell) change from 97-218r2 w.r.t. "PROCEDURE() name". My comments: - the previous version (specs) violated an explicit WG5 requirement (yes we are allowed to do this, but not without a good technical reason) - the current version is consistent with the EXTERNAL statement and existing handling of dummy arguments. Also, "leaves no way to specify an implicit interface subroutine" is slightly misleading, since it is possible to *DECLARE* an implicit interface subroutine in at least 2 ways: (i) there is no implicit mapping for the initial letter of the name, (ii) there is a reference to the name as a subroutine. Therefore I propose keeping to the definition as it stands in 99-007r1, i.e. "PROCEDURE() name" with no other specifications of "name" acts the same as "EXTERNAL name". 2. Other Problems Basically, when looked at rigorously, this section is a complete mess. [269:4-11] also needs changing to cope with abstract interfaces - at the moment we have dueling paragraphs (it says that procedures defined by an interface body are external procedures without regard for the "INTERFACE PROCEDURE()" status). Duplicate constraint [268:16-17]; this is already covered by [268:46]. Why is <> [269:6] in bold? The text here is not where it is "first defined with a specialized meaning" - it seems to be a simple reference to the syntax item . The "definitions" of <> and <> also leave much to be desired. However, I am not proposing to do anything about these at this time. The first 2 sentences of [269:4-11] have nothing to do with the rest of the paragraph; it should be broken into two paragraphs. We really need a term for an ordinary interface block (vs. an abstract interface block). I propose defining and using "generic interface block" and "specific interface block", both of which are pretty self-explanatory. The sentence at [269:43-44] is misleading - the PROCEDURE statement may list some of the "external procedures" in a generic interface, it does not necessarily list all of them. The "name in a procedure heading" clause ([269:7]) is not specific enough - there can be lots of names in a "procedure heading". Anyway, we don't seem to define what a procedure heading is - is it the initial statement of the interface body or is it all but the END statement? And [272:21] uses "name in a or " which at least avoids the undefined "procedure heading" term but still is not specific enough. 3. Edits {Move out-of-place section} Move section 5.2 in its entirety to new section 12.3.2.3 [87:1-25] Delete J3 note. {Clearly say that abstract interface characteristics must match for externals} [87:33] Add to end of paragraph "If is an external procedure, the characteristics specified by the abstract interface shall be consistent with those specified in the external procedure definition, except that the interface may specify a procedure that is not pure if the procedure is defined to be pure." {Delete redundant constraint} [268:16-17] Delete. {MJC: Check for characteristic agreement on dummy and pointer elsewhere} {Split off first two sentences which are independent.} [269:6] Break paragraph into two paragraphs after "." {Separate abstract interface blocks out from the rest.} [269:6] Replace "<> in an" by "interface block introduced by INTERFACE PROCEDURE() is an <>. An interface body in an abstract interface block specifies an <>. An interface block with a generic specification is a <>. An interface block introduced by INTERFACE (with no PROCEDURE() clause or generic specification) is a <>. An interface body in a generic or specific" {Fix non-specific "name in a procedure heading"} [269:7] Change "name in a procedure heading" to " in a or in a ". {Handle abstract interface blocks} [269:12] Delete "procedure's" Change "and" to "of the explicit specific interface. If the interface is for an external procedure". {Use new term rather than reference the BNF} [269:42] Change "An interface block with a generic specification" to "A generic interface block" {Without "those" there is no implication that it lists all of them.} [269:43] Delete "those". {Fill in missing bits about procedure pointers? I think that "must" is correct here - this is not a requirement, just a consequence of the constraint at [268:42-43].} [269:46] Before "A" insert "The characteristics of a procedure pointer are defined by a previous abstract interface block.". {Delete text we reworded and moved elsewhere} [270:27-28] Delete. {Make text more explicit} [272:21] Change "name given in a or " to " in a or in a "