J3/99-142 Date: 22 May 1999 To: J3 From: W. Clodius Subject: C interoperability terminology. I. Introduction The current editor of the Fortran 2000 draft has identified a large number of issues that should be resolved before publication of the final standard. Many of these issues are associated with new terms introduced to deal with recent additions such as C interfacing, procedure pointers, and object orientation. The new terms have several near redundancies, (procedures versus routines versus subprograms, ..), overloaded meanings (linkage), terms whose meaning differs from their usage in English (finalization), etc. The problems with current terminology both reflects the natural confusion in a rapidly evolving topic (the current draft of the Fortran standard) and is a source of confusion. Work on the current draft would benefit from a clearer terminology. This paper identifies a number of cases involving C interoperability where I believe the current terminology needs to be improved. Many of these are also identified in the editor’s notes to J3 in the F2000 draft. It is hoped that the terminology can be more clearly discussed by isolating them from other issues identified in the draft. If the suggestions in this report are useful I hope that a member of the C interoperability working group will adopt this paper as co-author, and, after appropriate corrections, submit the edits suggested by this paper for acceptance by the committee. The next section will identify cases where the terminology could be improved and list alternative terms. If more than one alternative is listed I will identify my preference. Edits implementing some of those corrections will be listed in the final section. II. Problematic terms A. Companion processor The term companion processor is used in awkward and confusing ways, particularly when a processor can be its own companion processor. It also seems awkward that a companion processor apparently cannot be another Fortran processor, that a companion processor apparently has to use BIND(C) and not a Fortran 90 INTERFACE, and that companionship appears to go one way (i.e, a Fortran subprogram can use a C "function", but a C "function cannot use a Fortran subprogram). I would prefer a terminology where the term companion is used for processors other than the Fortran processor and a different term, e.g., compatible, be used for the set of the Fortran processor and its compatible processor. I would also prefer a terminology which clearly distinguishes between the concept of a companion process in general, one that defines its interface to a Fortran processor in terms of the and one that defines its interface in terms of extern C linkage. I suggest something similar to the following terms the following terms: Companion processor - any compatible processor other than the Fortran processor itself. Companion Fortran processor - a companion processor that can define compatible entities without requiring a binding label. An example of a companion Fortran processor could be an Ada processor implementing the Fortran interface of Annex B of ISO/IEC 8652:1995. Companion C processor - a companion processor that defines compatible entities in terms of a binding label. Examples of a companion C processor could include a C processor or an Ada processor implementing the C interface of Annex B of ISO/IEC 8652:1995. Compatible processor - a mechanism that references and defines entities consistent in their definition with the definition provided to the Fortran processor. The Fortran processor is a compatible processor with itself, but it may designate compatible processors in addition to itself. B. Concepts related to entity definition, particularly procedure There are actually several related concepts that need to be clearly defined and distinguished consistently among the Fortran processor, companion Fortran processors, and companion C processors: 1. The definition of a procedure. The main problem here, as I see it, is that the draft is not being consistent in distinguishing between a definition and a declaration. In particular, there are contexts where the term definition implies only a definition and other contexts where it is a synonym for both definitions and declarations. 2. The declaration of a procedures interface. This is the equivalent of a Fortran INTERFACE and a C prototype. However there are times when this general concept needs to be discussed and the term definition is being used. I suggest the term declaration 3. The association of a name with a procedure definition including not only the "normal" name, but also the "binding label" overloading, and renaming on USE. This needs to be defined differently for companion Fortran processors and companion C processors. 4. the reference to a procedure. The C interoperability section uses the term call for this concept, most of the rest of the draft uses the term reference. 5. the association of a procedure reference with a procedure definition using name association, scoping, and overload resolution rules. The C interoperability section often uses the term linked (and linkage) for this concept, most of the rest of the draft uses the term associated. 6. lexical scoping - the functions of C are the only sources of procedure definitions and their definitions match exactly with their scope. In Fortran ENTRY introduces the concept of a procedure that shares scope with other procedures and the language must distinguish between their scope (which the rest of the draft terms a sub-program) and the actual procedure itself (or perhaps the name of the procedure) which the report terms a procedure. In every case I can think of C interoperability does not need to concern itself with Fortran's scoping rules and Fortran SUBROUTINEs, FUNCTIONs, and ENTRY statements should be collectively referred to as Fortran procedures. C. Bind label This term, and closely related terms, has several problems. The glossary does not define either the term "bind label", or the term "bind", while the term "label" defined in the glossary is inconsistent with its usage in "bind label". The term "bind label" defines something that in C terminology is a function name with external linkage, and roughly corresponds to what is, in Fortran terminology, the name of an external procedure. Why not use the term name instead of label and the term "link name" or "extern name" instead of "bind label"? (Escaping from the nominal topic of this article. Why not extend the semantics of the SEQUENCE attribute so that it implies true structural type equivalence? That extension appears to be compatible with current legal usage. Yes it would restrict optimization for derived types with the SEQUENCE attribute. Yes, such types might be slightly more error prone, although Modula 3 apparently had no problems with structural type equivalence. However, if optimization is a priority the SEQUENCE attribute can be avoided, while structural type equivalence would give types with the SEQUENCE attribute semantics closer to the concept of a sequence, and would give the language greater flexibility.) D. BINDNAME I also agree with the editor, BINDNAME is very confusing. It appears to be trying to deal with the case where there are two companion processors that do different forms of name mangling to the binding label. Its semantics, and hence the reason for having it in addition to NAME, are not clear and appear to be non-portable. A better approach for users, if they ever encounter this situation, is to write appropriate wrapper procedures and compile them separately with compiler switches specifying the appropriate companion processors. I strongly urge dropping BINDNAME, but have supplied no edits. III. Edits The following are edits suggested by some of the above comments and correct a few typographical errors. Originally I intended to implement all of the above, but time limits, the size of the edits suggested by the above, and the need for guidance from the committee made that impractical. Instead I have provided all edits related to companion processors and a few additional edits for unresolved issues that appeared to me to be most important to resolve in defining the overall approach of Fortran's C interoperability. Each set of edits will be given in the order of appearance in the draft and preceded by a small note that notes which, if any, unresolved issues the edit addresses, and, where useful, other concerns addressed by the edit. ---------------------------------------------------------------- Unresolved issues 144 and 145 (Note the following does not define the interaction of companion processors for entities other than procedures. I have also taken the liberty of deleting the final paragraph after NOTE 2.7 as I am in agreement with the editor.) Editor for pp. 20-21 replace Section 2.5.10 with 2.5.10 Compatible and companion processors A processor has one or more compatible processors. A compatible processor is a processor-dependent mechanism by which global data and procedures may be referenced or defined. A compatible processor may be a mechanism that references and defines such entities by a means other than Fortran (12.5.3), or it may be the Fortran processor itself. Compatible processors other than the Fortran processor itself are termed companion processors. The means by which the Fortran processor selects among companion processors are processor dependent. This standard allows two forms of companion processors. If a procedure is defined or referenced by a companion processor, and the procedure is associated with a subprogram without the BIND(C) attribute (12.5.1?) the companion processor is termed a companion Fortran processor. If a procedure is defined or referenced by a companion processor, and the procedure is associated with a subprogram with the BIND(C) attribute, the companion processor is termed a companion C processor. For procedures defined or referenced by a companion C processor, this standard refers to the procedure as a C function, although the function need not be defined by means of the C programming language. NOTE 2.7 A companion Fortran processor might or might not be a mechanism that conforms to the requirements of this standard. Similarly a companion C processor might or might not be a mechanism that conforms to the requirements of the C standard. For example, an Ada processor implementing the C interface of Annex B of ISO/IEC 8652:1995 may define a procedure, to be associated with a Fortran procedure with the BIND(C) attribute, while an Ada processor implementing the Fortran interface of Annex B may define a procedure, to be associated with a Fortran procedure with the EXTERNAL attribute. END NOTE 2.7 ---------------------------------------------------------------- unresolved issue 154 may be resolved by this as it implicitly limits the following discussion specifically to companion C processors Editor for p. 41 last paragraph of 4.5.0 replace "companion processor" with "companion C processor" ---------------------------------------------------------------- Editor for p. 285 the sentence before NOTE 12.31 replace the word "spe" with "be" ---------------------------------------------------------------- Editor for pp. 290 the first sentence of 12.5.2.7 replace "the companion processor" with "a companion C processor" ---------------------------------------------------------------- Editor for p. 291 in NOTE 12.35 replace the phrase "as Fortran names in" with "for Fortran names" ---------------------------------------------------------------- Unresolved issues 157 Editor for p. 291 rewrite the last sentence in NOTE 12.35 as The specification of a binding label for a procedure allows a companion C processor to refer to that procedure using that binding label, and the Fortran processor, and any companion Fortran processors, to refer to the procedure using the Fortran name. ---------------------------------------------------------------- Unresolved issues 159 and 160 Editor for pp. 292 replace item (1) before unresolved issue 159 with (1) interoperate (16.2.6) with a procedure that can be described by a C prototype with the same binding label as the procedure and is defined by means of a companion C processor or ---------------------------------------------------------------- Unresolved issue 164 may be resolved Editor for pp. 403 rewrite the first paragraph of Section 16 as Fortran provides a means of referring to procedures that are defined by means of the C programming language or procedures that can be described by C prototypes, even if they are not actually defined by means of C. Conversely, there is a means of specifying that a procedure defined by a Fortran subprogram can be referred to by a C function, or a companion C processor. In addition, there is a means of declaring global variables that are linked with C variables that have external linkage. ---------------------------------------------------------------- Unresolved issue 165 is partly addressed by this edit (NOTE: I don't know if there needs to be an additional constraint in the following that the C and Fortran entity definitions need to be unique. The last sentence of the rewrite is a kludge to avoid rewriting all of Section 16.2.) pp. 403 rewrite the first paragraphs of Section 16.2 as A Fortran entity interoperates with a C entity if (1) the Fortran entity can interoperate with the C entity, and (2) a companion C processor has been selected that allows reference to the C entity. A Fortran entity can interoperate with a C entity if (1) the C entity has extern linkage (2) the bind label of the Fortran entity is the same as the name of the C entity (3) the definitions of the Fortran entity and the C entity are consistent. That conditions under which the definitions of the Fortran entity and the C entity are said to be consistent are defined by this section. Consistent definitions will be noted by saying that the entities can interoperate, inconsistent definitions will be noted by saying that the entities cannot interoperate. ---------------------------------------------------------------- This is not a formal edit request, it is more a suggestion for the C interoperability team to be modified as they see fit. It needs to be fleshed out to be implemented. Subsequent subsections of 16.2 might be clearer if the last paragraph on page 403 is made into a subsection with the heading 16.2.1 Forbidden interoperability all explicitly forbidden interoperabilities were moved to that subsection, and subsequent subsections were renumbered accordingly. But I'll leave the details of that to someone more ambitious than I. ---------------------------------------------------------------- Unresolved issue 172 should be resolved (Note verify that the section numbers are correct. The use of binding label to distinguish between companion Fortran processors and companion C processors is not ideal, but the alternatives that came to mind struck me as too wordy, and possibly still incomplete.) Editor on p. 416 replace the definition of companion processor with Companion processor: (2.5.10) any compatible processor other than the Fortran processor itself. Companion Fortran processor: (2.5.10) a companion processor that can reference compatible entities without requiring a binding label. An example of a companion Fortran processor could be an Ada processor implementing the Fortran interface of Annex B of ISO/IEC 8652:1995. Companion C processor: (2.5.10) a companion processor that references compatible entities in terms of a binding label. Examples of a companion C processor could include a C processor or an Ada processor implementing the C interface of Annex B of ISO/IEC 8652:1995. Compatible processor: (2.5.10) a mechanism that references and defines entities consistent in their definition with the definition provided to the Fortran processor. The Fortran processor is a compatible processor with itself, but it may designate compatible processors in addition to itself.