2 Binding Methods
3 Principal Features of Fortran 90 Applicable to Bindings
4 Application of Binding Methods to Fortran 90
6 Obsolescent Features
7 Responsibility for Production of Bindings
Annex A. Use of Fortran 77 Bindings in a Fortran 90 Environment
This document has been prepared by the ISO/IEC JTC1/SC22/WG5 (Fortran) committee to aid those designing a binding for a functional standard to the ISO Fortran programming language, informally known as Fortran 90 (ref 9). The status of the document is a WG5 paper offering recommendations and advice; it is not intended to become a formal standard or a mandatory requirement.
Fortran 90 incorporates many new and more powerful features relative to its predecessor, informally known as Fortran 77 (ref 11). For example new facilities allow the programmer to extend the language with new data types and operations and allow the specification of much simpler user interfaces to external procedures. The purpose of this note is to draw these features to the attention of designers of bindings and to recommend ways in which they might be used in keeping with the aims of the language designers; this is not intended as a comprehensive overview of features new in Fortran 90.
At the same time it is emphasized that, apart from the minor points listed in Annex A, the Fortran 90 language contains Fortran 77 as a subset. Therefore in general any binding designed for use by a Fortran 77 program may be accessed also by a Fortran 90 program.
It is assumed that the reader has access to the ISO Technical Report on Guidelines for Language Bindings (ref 7) and to the ISO Fortran 90 standard, abbreviated below as GLB and F90 respectively.
While this document draws attention to a few salient features of the Fortran 90 language, the reader is referred to the Fortran standard for the full definition. A number of text books specifically on Fortran 90 have been published which may be of help; those known to WG5 at the time of writing are shown in part two of the bibliography (1.4.2).
The document concentrates on the user interface and makes few recommendations on the detailed programming of the functional code of any binding since this need not be coded wholly or even partly in Fortran.
Note should be taken of development work in SC22/WG11 on language-independent arithmetic, data types and procedure-calling mechanisms (refs 4- 6) which may affect bindings to Fortran 90 in future. In view of GLB guideline 5 they are not further considered here.
1.3 Levels of Standard
Fortran 90 is a unitary standard; there are no options or optional levels of conformance to the standard (cf GLB guideline 25). There is an optional auxiliary standard in preparation (ref 12); this is a definition of a set of functional extensions to Fortran 90 which includes a non-normative binding using Fortran 90. It does not affect the definition of the Fortran 90 language.
1.4.1 Standards, including work in development
1. Information Processing Systems - Computer Graphics - Graphics Kernel System (GKS) language bindings - Part 1: Fortran, ISO/IEC 8651/1.
2. Information Processing Systems - Computer Graphics - Three-Dimensional Extensions to GKS language bindings - Part 1: Fortran, ISO/IEC 8806/1.
3. Information Processing Systems - Computer Graphics - Programmer's Hierarchical Interactive Graphics System (PHIGS) language bindings - Part 1: Fortran, ISO/IEC 9593/1.
4. Information Technology - Programming Languages - Common Language-Independent Arithmetic, CD 10967 (1992).
5. Information Technology - Programming Languages - Common Language-Independent Datatypes, CD 11404 (1992).
6. Information Technology - Programming Languages - Common Language-Independent Procedure Calling Mechanism, Working Draft (ISO/SC22/WG11 N295, Dec 13, 1991).
7. Information Technology - Programming Languages, their Environments and System Software Interfaces - Guidelines for Language Bindings, TR 10182 (1993).
8. Posix Language Bindings/Fortran Language (in development).
9. Programming Languages - Fortran (Second Edition) ISO/IEC 1539:1991.
10. Programming Languages - Fortran (Second Edition) Technical Corrigendum (in preparation).
11. Programming Languages - Fortran ISO/IEC 1539:1980.
12. Varying Length Character Strings in Fortran, ISO/IEC CD 1539-2 (1992).
13. Terms of Reference for a SC22 Ad Hoc Group on Cross-language coordination, ISO/IEC JTC1/SC22 N1235 (September 1992).
14. Information Technology - 8- bit Single-byte Coded Graphic Character Sets ISO 8859, Parts 1 to 4: Latin alphabets 1 to 4; Part 5: Latin/Cyrillic; Part 6: Latin/Arabic; Part 7: Latin/Greek; Part 8: Latin/Hebrew; Part 9: Latin alphabet 5.
15. Computer Graphics Interface/Fortran Binding, ANSI X3H34/86-7.
16. Problems of Language Bindings, B.L.Meek, (ISO/SC22/N1278).
17. High Performance Fortran Language Specification, Version 1.0, May 3, 1993, High Performance Fortran Forum; reproduced in Scientific Programming, vol 2, no 1, June 1993.
18. Parallel Extensions for Fortran, ANSI X3H5/93-SD2-Revision A (April 2, 1993)
1.4.2 Fortran 90 texts
1. Fortran 90 - Counihan, Pitman, 1991, ISBN 0-273-03073-6.
2. Fortran 90; Approche par la Pratique - Lignelet, Série Informatique Éditions, Menton, 1993, ISBN 2-090615-01-4.
3. Fortran 90: eine informelle Einführung - Heisterkamp, BI- Wissenschaftsverlag, 1991, ISBN 3-411153-21-0.
4. Fortran 90 Explained - Metcalf and Reid, Oxford University Press, 1992, ISBN 0-19-853772-7 (also available in French, Japanese and Russian translation).
5. Fortran 90 Handbook - Adams, Brainerd, Martin, Smith and Wagener, McGraw-Hill, 1992, ISBN 0-07-000406-4.
6. Fortran 90; Initiation à partir du Fortran 77 - Aberti, Série Informatique Éditions, Menton, 1992, ISBN 2-090615-00-6.
7. Fortran 90 Referenz-Handbuch: der neue Fortran-Standard - Gehrke, Carl Hansen Verlag, 1991, ISBN 3-446163-21-2.
8. Programmer's Guide to Fortran 90 - Brainerd, Goldberg and Adams, McGraw-Hill, 1990, ISBN 0-07-000248-7.
9. Programmieren in Fortran - Langer, Springer Verlag, 1993, ISBN 0-387-82446-4.
10. Programmierung in Fortran 90 - Schobert, Oldenburg, 1991.
11. Programming in Fortran 90 - Morgan and Schonfelder, Blackwell Scientific Publications, 1993, ISBN 0-632028-38-6.
12. Software Entwicklung in Fortran 90 - Überhuber and Meditz, Springer Verlag, 1993, ISBN 0-387-82450-2.
The cooperation of Don Nelson, project editor of GLB, in providing a machine-readable copy of a WG11 working draft of GLB, is gratefully acknowledged.
2 Binding Methods
2.1 Definition of Binding Methods
The five methods of binding discussed in GLB are:
1. Provide a completely defined procedural interface (the System Facility Standard Procedural Interface).
2. Provide a procedural interface definition language (User-Defined Procedural Interface).
3. Provide extensions to the programming language, using native syntax.
4. Allow alien syntax to be embedded in the programming language.
5. Bind pre-existing language elements.
More recent work on cross-language coordination (ref 13) has suggested two additional methods:
6. Direct normative reference from the language standard to the cross-language facility standard.
7. Direct inclusion of (part of) the text of the cross-language facility standard in the language standard.
2.2 Advantages and Disadvantages of Binding Methods in General
This section reproduces parts of section 2 of GLB to demonstrate the advantages and disadvantages of binding methods in general terms. GLB section 2 contains fuller discussion of the various methods.
[From GLB 2.1 - Introduction] A pre- processor is necessary for Method 4 above, and optional for Method 3. Method 1 does not require a pre- processor but it may be useful to provide a utility that checks the syntax of all the procedure calls. The function of a pre- processor is to scan a program source text, to identify alien syntax or syntax associated with a given facility, and to replace this text by host language constructs (for example, calls to system functions) that can be compiled by the standard compiler.
The advantages of a pre- processor are:
A pre- processor can often carry out semantic checking not provided by the language compilers.
A pre- processor can be independent of the particular language compiler.
A pre- processor approach avoids problems that result from tampering with an existing language standard or with certified compilers.
If the system facility is enhanced, it is easier to modify a pre- processor than a full compiler.
The disadvantages are:
A pre- processor requires an extra pass through the source.
There may be a problem with multiple pre- processors for different system facilities existing in the same environment.
A pre- processor may produce code unfamiliar to the programmer and make debugging more difficult - for example, it may change statement numbers.
Depending on the language extensions, it may be necessary to analyze the syntax of most of the language to detect the code to be replaced.
There is often more than one way to implement a given method. In addition, it may be necessary to implement more than one method for any given facility.
[From GLB 2.2 - Method 1] Method 1 is appropriate when the syntax of the interface provided for each system function is fairly simple and can be fully defined by a few parameters. The method can become unwieldy when the functions that can be invoked use a large number of data types whose structure may be unknown until the time of invocation, and require parameters or data types that are unknown in structure until the time of invocation.
Use of Method 1 requires that the procedural interface be redefined for each programming language, in terms of the syntax and data types of that language. Thus, separate language binding standards to the same functional interface standard are created.
Method 1 has been used by GKS and other graphics draft standards, where the syntax of the parameters is fairly simple.
It should be noted that, if languages used a common procedure calling mechanism and equivalent sets of data types (ISO/IEC JTC1 has assigned work items on these topics to SC22/WG11), then it would be possible to derive system facility standard procedural interfaces from the abstract definitions. It would also be possible to derive system facility standard procedural interfaces from abstract definitions under other conditions, particularly for languages of sufficient abstraction (like Pascal and Ada).
[From GLB 2.3 - Method 2] Method 2 allows the binding document to be easily adapted to different programming languages, since the binding only deals with data types. The naming of procedures and parameters is done by the user and not the binding specifiers. The procedural interface definitions are compiled and the resulting object module must be linked both to the application program and to the system facility.
Advantages of Method 2 are:
It may provide early diagnosis of errors.
It is processed once and may allow specific optimization (for example, optimization of query searches) leading to run- time economies.
Modules may be shared among application programs, since they exist independently.
The task of creating modules may be specialized and managed outside of the user's program.
Disadvantages of Method 2 are:
The definition of modules is an extra design step and risks poor usability when the programmer has to define his own modules.
The procedural interface definition language is another language to learn unless the procedural interface language is part of the host language already.
There is generally an administrative overhead for managing modules to ensure that they get recompiled and relinked when necessary.
Porting an application involves porting the program and all the referenced procedural interface definition language modules.
An additional compiler has to be provided for the procedural interface language unless the procedural interface language is part of the host language already.
[From GLB 2.4 - Method 3] This method is viable only when the system facility is stable and when the application requirements are well understood, since the cost of changes to programming language standards is high.
The main advantage is usability. The users of the language have little extra to learn except the new facilities. It also allows the language developers, when defining new versions of the language, to choose a conforming subset of the facilities or to change the appearance of existing language facilities if they believe this is helpful to their users. Another advantage is that new data types appropriate to the system facility can be constructed.
The disadvantages are that Method 3 ties a compiler to a particular system facility definition. It also ties the language specification to that of the system facility, making it highly desirable to process the standardization of both specifications together if enhancements are needed. It may also be more difficult to use this method in a mixed- language environment, since the same facilities may have confusingly different appearances in different host languages.
[From GLB 2.5 - Method 4] The advantage of Method 4 over Method 2 is that simple programs, particularly those that may have a short life, may be easier to create. The advantage of Method 4 over Method 3 is that the independence of host language specifications from system facility specifications is maintained, so development of each can progress more quickly.
The disadvantage of Method 4 over Method 2 is that this method substantially complicates the relationships between applications and system facilities. Although the alien syntax should be very similar for all host languages, the pre- processor will need to 'know about' the conventions of each host language to be able to generate the correct interfacing code.
The disadvantage of Method 4 compared with Method 3 is that the programmer has to know two languages and may be confused by the differences between them.
[From GLB 2.6 - Method 5] The advantage [of method 5] is that pre- existing constructs are used and no extra work in binding needs to be done. If that facility is already present in the language, then making use of that facility avoids unnecessary perturbations to the language.
Care should be taken that the language construct fully meets the requirements of the system facility.
2.3 Applicability of Fortran 90 Facilities to Binding Methods
WG5 considers that the MODULE offers the Fortran user such powerful facilities that it will become an intrinsic part of Fortran 90 usage. Therefore it is not useful to discuss the binding methods of GLB in this document without incorporating the concepts of modules into each method as appropriate. Thus for example the simple procedural interface in the style of Fortran 77 usage is assumed to be enhanced to involve procedural interfaces used in conjunction with the language extension facilities of modules.
Continue to 2nd half of Guidelines