1.1 Status of the Document

This document is a compilation of the experience and knowledge gained by the members of ISO/IEC JTC1/SC22/WG11 (Techniques for Bindings) from the generation of programmers' interfaces to FUNCTIONAL INTERFACE STANDARDS. Although current experience was derived from the fields of computer graphics and database management, the problems discussed are thought to be generally applicable for mappings of other functional interface standards to programming languages. This document is intended

This document is incomplete; the authors have concentrated on those areas where experience and expertise was readily available. The ideas and issues brought forward here emerged from more than ten years of work, and are represented in International Standards.

Section 2 of this document contains the results of a survey of current methods used for language binding development. Characteristics of each method are given, followed by reasons for the selection of the method.

Application of the methods has suggested some guidelines that are presented in Section 3. Sections 2 and 3 contain documentation of the current state of language binding efforts; Section 4 addresses future directions for language bindings.

Circulation of this document is necessary at this stage, as input and discussion from representatives of ISO/IEC JTC1/SC21 (functional specification standards developers), ISO/IEC JTC1/SC24 (computer graphics standards developers), and ISO/IEC JTC1/SC22 (language standards developers) is urgently sought. The document in its current form may be useful for those about to embark on language binding developments.

This document is based on experience gained in the standardization of two major areas in information processing. One area covers programming languages. The other area is composed of the services necessary to an application program to achieve its goal. The services are divided into coherent groups, each referred to as a SYSTEM FACILITY, that are accessed through a FUNCTIONAL INTERFACE. The specification of a system facility, referred to as a FUNCTIONAL SPECIFICATION, defines a collection of SYSTEM FUNCTIONS, each of which carries out some well-defined service.

Since in principle there is no reason why a particular system facility should not be used by a program, regardless of the language in which it is written, it is the practice of system facility specifiers to define an 'abstract' functional interface that is language independent. In this way, the concepts in a particular system facility may be refined by experts in that area without regard for language peculiarities. An internally coherent view of a particular system facility is defined, relating the system functions to each other in a consistent way and relating the system functions to other layers within the system facility, including protocols for communication with other objects in the total system.

However, if these two areas are standardized independently, it is not possible to guarantee that programs from one operating environment can be moved to another, even if the programs are written in a standard programming language and use only standard system facilities. A language binding of a system facility to a programming language provides language syntax that maps the system facility's functional interface. This allows a program written in the language to access the system functions constituting the system facility in a standard way. The purpose of a language binding is to achieve portability of a program that uses particular facilities in a particular language. Examples of system facilities that have had language bindings developed for them are GKS, NDL, and SQL (see Section 1.3, References and Bibliography). It is anticipated that further language binding development will be required. Some system facilities currently being standardized have no language bindings and additional system facilities will be standardized. There is a possibility of n x m language bindings, where n is the number of languages and m the number of system facilities.

The scope of this document is to classify language binding methods, reporting on particular instances in detail, and to produce suggested guidelines for future language binding standards.

Note that the language bindings and the abstract facility interfaces must have a compatible run time representation, but the abstract facility does not necessarily have to be written in the host language. For example, if the application program is using a Pascal language binding and the corresponding facility is written in FORTRAN, there must be a compatible run time representation in that operating environment. How this compatibility is achieved is outside the scope of these guidelines. This is generally a property of the operating environment defined by the implementor, and is reviewed briefly in this document.

ISO/IEC 1539:1991, Information Technology - Programming languages - FORTRAN.

ISO/IEC 1989:1985, Programming Languages - COBOL.

ISO/IEC 1989:1985/Amd.1:1992, Programming Languages - COBOL - Amendment 1.

ISO 6373:1984, Data processing - Programming languages - Minimal BASIC.

ISO 7185:1990, Information technology - Programming languages - Pascal.

ISO 7942:1985, .Information processing systems - Computer graphics - Graphical Kernel System (GKS) functional description.

ISO 8651-1:1988, Information processing systems - Computer graphics - Graphical Kernel System (GKS) language bindings - Part 1: FORTRAN.

ISO 8651-2:1988, Information processing systems - Computer graphics - Graphical Kernel System (GKS) language bindings - Part 2: Pascal.

ISO 8651-3:1988, Information processing systems - Computer graphics - Graphical Kernel System (GKS) language bindings - Part 3: Ada.

ISO 8651-4:1988, Information technology - Computer graphics - Graphical Kernel System (GKS) language bindings - Part 4: C.

ISO 8652:1987, Programming Languages - Ada.

ISO 8805:1988, Information processing systems - Computer graphics - Graphical Kernel System for Three Dimensions (GKS-3D) gfunctional description.

ISO/IEC 8806-1:, Information technology systems - Computer graphics - Graphical Kernel System for Three Dimensions (GKS-3D) language bindings - Part 1: FORTRAN.

ISO 8907:1987, Information processing systems - Database Languages - NDL.

ISO/IEC 9075:1992, Information technology - Database Languages - SQL.

ISO/IEC 9592:1984, Information processing systems - Computer Graphics - Programmer's Hierarchical Interactive Graphics System (PHIGS).

ISO/IEC 9593-1:1990, Information processing systems - Computer graphics - Programmer's Hierarchical Interactive Graphics System (PHIGS) language bindings - Part 1: FORTRAN.

ISO/IEC 9593-2:, Information technology - Computer Graphics - Programmer's Hierarchical Interactive Graphics System (PHIGS) language bindings - Part 2: Extended Pascal.

ISO/IEC 9593-3:1990, Information technology - Computer Graphics - Programmer's Hierarchical Interactive Graphics System (PHIGS) language bindings - Part 3: Ada.

ISO/IEC 9593-4:1991, Information technology - Computer Graphics - Programmer's Hierarchical Interactive Graphics System (PHIGS) language bindings - Part 4: C.

ISO/IEC 9899:1990, Programming languages - 'C'.

ISO/IEC 10206:1991, Information Technology - Programming languages - Extended Pascal.

C. Osland, Case Study of GKS Development, Eurographics Tutorials 1983, Springer.

J. R. Gallop, C. Osland, Experience with Implementing GKS on a Perq and Other Computers, Computer Graphics Forum 9(7), North-Holland 1985.

F. R. A. Hopgood, D. Duce,J. R. Gallop, D. Sutcliffe, Introduction to the Graphical Kernel System (GKS), Academic Press, 1983.

M. Sparks, J. R. Gallop, Language Bindings for Computer Graphics Standards, IEEE Computer Graphics and Applications, Vol 6, Number 8, August 1986.

M. Sparks, Graphics Language Bindings, Computer Graphics Forum, Journal of the European Association for Computer Graphics, vol. 4(4) 1985.

M. Sparks, Graphics Standards Bindings - What Are They and When Can We Use Them?, Computer Graphics/November 1985.

Language Binding Generic Issues (document within ISO/IEC JTC1 SC24/WG4 and ISO/IEC JTC1 SC22/WG11)

ABSTRACT SERVICE INTERFACE: An interface having an abstract definition that defines the format and the semantics of the function invoked independently of the concrete syntax (actual representation) of the values and the invocation mechanism.

ALIEN SYNTAX: Syntax of a language other than the host language.

CGI: Computer Graphics Interface standard (ISO DP) - a functional specification of the computer graphics programming system facility.

EMBEDDED ALIEN SYNTAX: Statements in a special language for access to a system facility, included in a source program written in a standard programming language.

EXTERNAL IDENTIFIER: An identifier that is visible outside of a program.

FUNCTIONAL INTERFACE: The abstract definition of the interface to a system facility by which system functions are provided.

FUNCTIONAL SPECIFICATION: The specification of a system facility. In the context of this document, the functional specification is normally a potential or actual standard. For each system function the specification defines the parameters for invocation and their effects.

GKS: Graphical Kernel System standard (ISO/IEC 7942) - a functional specification of the computer graphics programming system facility.

HOST LANGUAGE: The programming language for which a standard language binding is produced; the language in which a program is written.

IDENTIFIER: Name of an object in an application program that uses a system facility.

IMPLEMENTATION-DEFINED: Possibly differing between different processors for the same language, but required by the language standard to be defined and documented by the implementor.

IMPLEMENTATION-DEPENDENT: Possibly differing between different processors for the same language, and not necessarily defined for any particular processor.

IMPLEMENTOR: The individual or organization that realizes a system facility through software, providing access to the system functions by means of the standard language bindings.

LANGUAGE BINDING OF f TO l or l LANGUAGE BINDING OF f: A specification of the standard interface to facility f for programs written in language l.

LANGUAGE COMMITTEE: The ISO technical Subcommittee or Working Group responsible for the definition of a programming language standard.

MDL: A language for the specification of an interface to a generic system facility, the MDL (module definition language) is used to generate a module to support the specific system facility access needs of an application program.

NDL: Database Language NDL may be used to define the structure of a database using the network model of data.NDL is defined in IS 8907. (See Section 1.3, References). The standard also includes the data manipulation functions and their language bindings.

PHIGS: Programmers Hierarchical Interactive Graphics System standard (ISO/IEC 9593) - a functional specification of the 3-D computer graphics programming system facility.

PROCEDURAL BINDING (system facility standard procedural interface): The definition of the interface to a system facility available to users of a standard programming language through procedure calls.

PROCEDURAL INTERFACE DEFINITION LANGUAGE: A language for defining specific procedures for interfacing to a system facility as used, for example, in IS 8907 Database Language NDL.

PROCEDURE: A general term used in this document to cover a programming language concept which has different names in different programming languages - subroutine and function in FORTRAN, procedure and function in Pascal, etc. A procedure is a programming language dependent method for accessing one or more system functions from a program. A procedure has a name and a set of formal parameters with defined data types. Invoking a procedure transfers control to that procedure.

PROCESSOR: A system or mechanism that accepts a program as input, prepares it for execution, and executes the process so defined with data to produce results.

PROGRAMMING LANGUAGE EXTENSIONS WITH NATIVE SYNTAX or native syntax binding: The functionality of the system facilities is incorporated into the host programming language so that the system functions appear as natural parts of the language. The compiler processes the language extensions and generates the appropriate calls to the system facility functions.

SQL: Database Language SQL (Structured Query Language) defines the structure of a database using the Relational model of data. Database Language SQL is defined in IS 9075. (See Section 1.3, References). The standard also includes the data manipulation functions and their language bindings.

SYSTEM FACILITY: A coherent collection of services to be made available in some way to an application program. The system facility may be defined as a set of discrete system functions with an abstract service interface.

SYSTEM FACILITY COMMITTEE: The ISO technical subcommittee or Working Group responsible for the development of the functional specification of a system facility.

SYSTEM FUNCTION: An individual component of a system facility, which normally has an identifying title and possibly some parameters. A system function's actions are defined by its relationships to other system functions in the same system facility.

This section discusses the binding development problem in general by documenting a number of different approaches to bindings. Each approach has its own characteristics from the points of view of the user, the implementor, and the specifiers of standards.

The first task in specifying a binding of a system facility is to determine the usability, stability, and implementation goals of both the binding and the system facility, and to use these to help select the best method.

The functional binding methods are:

Before addressing the individual methods, a discussion of a general issue that affects programming language implementations is indicated. This issue is whether to increase the capability of a given compiler to encompass the system facility, or to provide a pre-processor. Though this is of no direct concern to language binding developers, they may wish to consider the feasibility of each option when choosing a method.

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:

The disadvantages are:

In the following sections, each functional binding method is discussed, circumstances that suggest a method be used or avoided are given, and relevant advantages and disadvantages are defined.

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.

With functional binding Method 1, the system facility is designed to support a fixed number of procedures. Each procedure has formal parameters of defined data types and each procedure invocation passes actual parameter values which match the data types.

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.

It is often useful to define subsets of the facility to suit different modes of use. For example, where the functions are largely independent and a program only requires a few of them, it may be possible to reduce the size of the run-time system by omitting portions of the system facility. These subsets are reflected by levels of conformance to the functional interface standard.

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).

With functional binding Method 2, the run-time procedural interface is defined by the user, and the system functions invoked by the procedures are defined in a language appropriate to the system facility.

This method is appropriate when the interfaces to the system functions provided by the system facility are too complex to be defined by a few parameters, and when they cannot be easily contained in an exhaustive list.

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:

Disadvantages of Method 2 are:

Database facilities use this method, where a Procedural Interface Definition Language (in the database standards this is referred to as a Module Definition Language), containing both declarations and procedural statements, is provided. A module may declare the data to be accessed as a view of the database (as it may reference a predefined view) and it defines both the form and the execution of database procedures.

With functional binding Method 3, the functionality of the system facilities is incorporated into the host programming language so that the system functions appear as natural parts of the language. The compiler processes the language extensions and generates the appropriate calls to the system facility functions.

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.

Method 3 has been tried with the COBOL and FORTRAN database facilities (Codasyl and ANSI) and with the graphics chapter for Basic.

With functional binding Method 4, the system facilities are considered to be 'driven' by statements written in a 'system facility language' rather than in the host programming language. The embedded alien syntax must be clearly distinguishable from the host language so that it can be processed by a pre-processor.

Method 4 is suitable when the system facilities are too complex to be invoked by simple procedures (as for Method 2, User-Defined Procedural Interfaces). The method could be implemented by having the pre-processor generate Module Definitions as in Method 2.

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.

Method 4 is one of the options in the ISO database standards.

In some cases, the host language may contain language elements that can be directly identified with corresponding elements of the abstract system facility. For example, in a binding to a system facility that opened and closed files, the host language may already contain constructs for opening and closing files.

The advantage 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.

The subsections above have described five different methods for developing functional bindings, and the circumstances in which they can be used. None of the methods is appropriate in all circumstances, or for all languages. In practice, a combination of methods may be appropriate. In some languages it is necessary to combine Method 4 with Method 5.

It is possible, and often desirable, for a system facility to provide more than one method of binding, to give the implementor and user a choice. However, if an implementor provides only one of the standard methods, the user has no choice, and, unless there is a recognized way of converting between methods, portability problems result.

The objective of a standard language binding is to enable a program to be portable when it is written in a standard programming language and accesses a standard system facility. Often the system facility is written in a different language from the application program and requires a certain compatibility between the implementations of the two source language compilers. Of course, similar compatibility is necessary for different compiler implementations of the same source language. In particular:

Often, but not always, the hardware and operating system will determine appropriate standards or conventions for the representation of primitive data types and inter-program calls. Where there are mismatches, it is necessary for the implementor to create a layer of software to perform conversions between alternative data type representations or procedure calling mechanisms. There are now ISO/IEC JTC1 work items addressing a) and b) above. These are: work item 22.16 - Specification for a Model for Common Language-Independent Procedure Calling Mechanisms, and work item 22.17 - Specification for a Set of Common Language-Independent Data Types.

The methods described have been used in current ISO standards for database and graphics. Some papers defining bindings for communications facilities have also been reviewed, but the strategy to be adopted for ISO OSI bindings is yet to be determined.

This section describes some organizational guidelines that should be followed in order to facilitate the generation of binding standards. A general statement of each guideline is given, followed by some discussion. The guidelines appear in no particular order.

Standard bindings of some form should be developed for all standard system facilities that may be accessed from a standard programming language.

Here, "standard" means that an ISO standard or draft standard exists for both the system facility and the language.

There are standards describing system facilities which do not have standard language bindings associated with them. Lack of a standard may lead to implementor-defined interfaces, causing loss of portability.

Either the language committee or the system facility committee should have primary responsibility for the language binding.

In this area, current practice is 'whichever committee perceives the need for a binding' or 'if the language has an external procedure call mechanism, then the system facility, otherwise the language committee'. Unfortunately, sometimes a binding is required, yet no-one takes the initiative to start binding work; some method for resolving this impasse is required.

It is expected that it is the primary responsibility of the system facility committee to establish a reference binding to an arbitrary language and a generic binding. Subsequent bindings should be the responsibility of the appropriate language committees. In practice it is expected that the system facility committee will seek support from the applicable language committee in the creation of an arbitrary binding. This would increase the likelihood of getting a full range of language bindings to make a system facility useable. The system facility committee is more likely to have an interest in making the facilities accessible; furthermore, language committees might not have the necessary expertise to develop bindings to specialized facilities. Part of the primary responsibility is to respond to public comments.

Whichever committee is responsible for a particular binding, the other committee needs o be consulted as early as possible. The two committees have complementary responsibilities and concerns.

A system facility committee is concerned with

A language committee is concerned with

Both committees are concerned with ease of use and orthogonality of concepts.

Specific guidelines should be produced alongside standards for particular system facilities and particular programming languages.

Potentially, there is an n x m problem of agreeing and processing n language bindings to m system facilities. Ideally, the development of appropriate guidelines should reduce the problem to one of order n+m.

Binding guidelines could be published as appendices to standards, and in some cases a supplemental standard could be considered. Sample programs would also be helpful. Publication of such guidelines by language committees would help not only system facility committees, but also any producers of packages needing bindings to languages, and would thus help promote portability.

Draft proposals for bindings should not progress beyond the standardization stage of the system facility or the language.

In addition, no system facility should progress to DIS (Draft International Standard) or IS (International Standard) until there is at least one language binding at or above the level of DP (Draft Proposed International Standard) or DIS, respectively. Users cannot fully judge a semantic standard without seeing the specific syntax which is their only access to it. Also, there are some difficulties with abstract semantics which are only revealed by the production of a language binding. Reference ISSUE 1: What should be the criteria for determining if the functional interface standard should be bound to a particular programming language?

This section contains guidelines that are general over all binding methods.

Language bindings to the same system facility should be similar in those respects where the languages are similar.

A functional specification might have a system facility data type that is easily represented in some languages but not in others. For example, GKS uses points which can easily be represented as records in Pascal and Ada, but not in FORTRAN. It seems unreasonable for the Pascal and Ada bindings to be constrained by the FORTRAN binding. On the other hand, after language bindings for a few very dissimilar languages have been produced, bindings for additional languages might be produced by analogy.

Different language bindings to a system facility should not be the cause of substantial differences in program structure except where warranted by substantial language differences.

Some factors inherent in the language substantially influence the structure of a program. For example, a program written in a language with a WHILE construct is likely to possess a different structure than a language without such a construct. However, the different bindings of the system facilities should not be the cause of substantial differences in structure. An example of such a problem would be if a functional parameter is bound as an output parameter in one language binding and as an input parameter in another.

This principle may well break down when the languages have different processing paradigms or other deep concepts, such as the inherent differences between imperative and functional languages.

A binding must be reviewed and, if necessary, updated each time the system facility or the language standard is enhanced. (The forward compatibility requirements of the user must be identified and taken into consideration when any of the standards is enhanced).

Reference ISSUE 2: To what event(s) should new versions of a binding be tied?

Bindings should take account of likely language processor limits. (A standard-conforming processor may fail to process a standard-conforming program if it is caused to exceed its limits on size, complexity, etc.) Approaches to handling such limits may appear in guidelines to bindings implementors and working papers.

As an example, a language processor may fail if its limits on number and length of identifiers are exceeded.

Reference ISSUE 3: How are 'real world' limitations of the standard taken into consideration?

This section contains recommendations for the preparation of standard functional specifications for system facilities. These recommendations are intended to assist the subsequent preparation of language bindings to those functional specifications.

A functional specification should use an abstract description, and should avoid being influenced by a particular programming language.

This very general statement is amplified in some of the guidelines that follow. This guideline allows a language binding to be appropriate to its host language. There is a need for a formal notation for the definition of abstract interfaces. The notation would need to be independent of programming languages and of implementations.

A data type in a functional specification is not intended to correspond with a particular internal representation in the host computer, but rather is an abstract entity intended to be mapped to the most appropriate type in the host language.

Specifying and implementing language bindings to functional standards are made more difficult both by differences between superficially similar data types in different languages, and by differences between standard-conforming implementations of the same datatype of one language (which may be permitted through properties of the datatype being left as implementation-defined or implementation-dependent in the standard). Such differences make it difficult to be certain what properties a particular datatype will possess in a given case. Basing the functional standard on a particular implementation model for a particular language is likely to increase such problems, and Guideline 10 is aimed at discouraging this.

In general, the task of specifying and implementing bindings will be greatly eased by language standards specifying required properties of datatypes more precisely than has been customary in the past, and also by greater consistency and commonality in these respects between different languages (an issue addressed by ISO/IEC JTC1 work item 22.17). This will aid the task of implementors in ensuring compatible representations and consistent implementations of bindings, and enhance the portability of application programs which need to invoke such bindings.

Parameters that take values that have predefined meanings should be defined in abstract terms, and not necessarily be associated with numeric values. In certain situations, however, an ordering may be needed.

This guideline is intended to encourage the use of the enumerated data type, as in Pascal and Ada. Early drafts of GKS used numeric values unnecessarily. Note that enumerated types will need encodings for languages such as FORTRAN. For portability, these encodings should be defined in the system specification.

The system facility should recover from errors whenever possible. A report on the status of errors should be returned to the host program where that is possible. It should be possible for the host program to determine where the error arises in the system facility.

This section contains recommended guidelines for the methods described in Section 2.

The task of a procedural language binding is to express the system functions and data types of a particular system facility in terms of the constructs available in the host language.

This section attempts to document the experiences and ideas resulting from actual development of procedural language bindings of the graphical functional interface standards to programming languages. These bindings use procedures (rather than language modifications or a separate language), whose names and argument lists are defined in the binding standard.

A group of generic issues has been discovered, discussed, and resolved for all language bindings of graphics. Most of this section is concerned with guidelines arising from these generic issues. In addition, it is recommended that each language committee keeps a separate list of language-specific issues.

First, some general guidelines for which no issues were generated. This group of guidelines includes statements about the relationship between the functional specification and the language binding, suggested action for both types of committees involved, and some recommendations for programming language committees resulting from the experiences of bindings developed to those languages. Following these recommendations, a set of recommendations for procedural bindings, based on issues, is provided.

The following guidelines have been used in the GKS functional interface standard and may be applicable to other functional specifications.

The language binding needs to specify, for each system function name, exactly one identifier acceptable to the language.

The names used for system functions in the standard are merely tools for describing the semantics of the standard; they should be replaced by actual identifiers conforming to the restrictions of the host language. A one-to-one mapping from language functions to system functions is preferred.

A method of avoiding name-clashes is needed for some languages; the name of a system function must not clash with a name in a binding to a different system facility.

Distinguishing between the names of system functions should not rely on case sensitivity alone.

The language binding needs to specify, for each of the system facility data types, a corresponding data type acceptable to the language. Where convenient for the host language, additional data types may be specified in terms of the system facility data types.

The data types used in the functional interface standard are merely tools for describing the semantics of the standard; they should be mapped to host language data types in the binding. In a language which allows aggregation of data into records, data may be grouped but group elements must be system facility data types.

The language binding needs to specify, for each system function, how the corresponding language function is to be invoked, and the means whereby each of the formal input parameters is transmitted to the language function and each of the formal output parameters is received from the language function.

Where the host language allows, the system functions are mapped to language functions or procedures. The parameters are typically transmitted via a parameter list. The items in such a list may either be, or be references to, items of the data types corresponding to the system data types, or aggregates of these types. Parameter passing attributes such as Ada's IN, OUT, and IN OUT or Pascal's VAR should be specified.

The language binding needs to specify a set of identifiers acceptable to the language, which may be used by an implementation for internal communication.

An implementation is normally unable to restrict its use of externally visible identifiers to those specified as a consequence of the preceding guidelines. Suggested identifiers for use by the implementation help circumvent clashes. Still, applications must avoid using identifiers from the sets required and suggested by the binding.

Because this set of identifiers is, in general, a superset of the names specified by the language binding, programs transported to an implementation from other implementations of the same binding might have used names that clash. Documentation is required to enable potential clashes to be detected.

The documentation of a system facility implementation needs to include a list of all identifiers for procedures, functions, global data aggregates, and files that are visible either to an application program or to the underlying operating system.

As discussed earlier the potential exists for an n x m problem when developing n procedural language bindings to m system facilities. To begin to solve this problem, certain actions may be taken within the area of expertise of one committee or the other.

Lists of abbreviations for function names should be part of a guideline drawn up by the developers of the system facility.

See also guidelines 43 and 44.

Each language should have guidelines for selecting the abbreviation list to use.

See also guidelines 43 and 44.

Whether a procedural binding or a native syntax binding is developed depends on the host programming language, and is the decision of the language committee.

How compound data types are bound depends on the host programming language.

This section contains some proposed recommendations to be considered in the preparation of future programming language standards.

Some agreement is needed on cross-calling of procedures between languages, with particular attention to the passing of data. Standardization in this area would allow system facilities to be accessible from more than one language, with a minimal portable layer between.

It should not be an error in a language if the dynamically specified length of an array is zero.

Language standards should not unduly restrict the number of characters in external identifiers. They should allow occurrences of at least one punctuation symbol in identifiers, and at least one of the punctuation symbols allowed should be significant in the spelling of the identifier.

The design objectives of language bindings include:

Facility language bindings should achieve all these goals. Metrics for measuring both objectives and achievement of these goals are under study elsewhere.

In practice, the binding developer is required to make sensible trade-offs between these goals. The guidelines are offered here to assist in making these trade-offs and to encourage some consistency within ISO on the way the trade-offs are made for different system facilities.

When developing a binding of a functional interface standard to a programming language, there are times when a trade-off must be made between using 'language-type' facilities (which would be expected by an expert in that language) and making the binding easy to use by an inexpert programmer. In addition, there are times when steps could be taken to make the bindings to similar languages look more alike (for portability of programmers' expertise across languages).

Some arguments which have been brought up are:

The complexity of the problem has been acknowledged, and no definite conclusions have been drawn. The following guidelines reflect the consideration of all of the above goals, with preference given to different goals for different situations. The guidelines arise from some issues, a complete set of which may be found in Annex B.

All system functions should appear atomic to the application program.

This guideline avoids unintentional, inconsistent state changes and incomplete actions. A procedural binding should not map single system functions into sequences of language procedures called by the application program, except in the case where these procedures do not change the state of the system facility. (For example, in GKS, for "inquiry functions" in certain language bindings, the procedures may need to be called once for each element of a dynamic list; however, these functions do not change the state of the system facility.)

The binding of a system facility to a language should use appropriate facilities of the basic level of the language standard, to assist in usability, performance, etc. It should not attempt to simplify implementation by use of a restricted subset of the basic language level. Facilities in higher optional levels of the language standard, however, should be used only if necessary.

As an example, an Extended Pascal binding should use all appropriate facilities of "Level 0" of the standard, but should not use facilities of "Level 1" unless necessary.

Reference ISSUE 4: How much of the 'spirit' of the language is taken into consideration when developing a binding?

The reader of the binding specification should be assumed to be a programmer skilled both in the language and in the system facility.

Reference ISSUE 5: For what types of programmers should the bindings be developed?

Bindings for each programming language for which a need exists must be prepared. This does not preclude the development of a generic binding for less used languages.

Reference ISSUE 6: Should a generic binding (i.e., a single binding that can be used for many programming languages) be the only binding developed for the functional interface standard?

The development of language specific bindings must be supported for those functional interface standards that require such bindings; however, a single generic binding may be supported for rapid adoption and implementation of such functional interface standards as those in the database arena.

Reference ISSUE 7: Should the development of a generic binding be supported?

If a generic binding is required, only one should be developed.

Reference ISSUE 8: If the development of a generic binding is supported, should the development of more than one generic binding be supported?

Within the stated goals, the facilities used should be as consistent throughout the many language bindings to a functional interface standard as possible.

Reference ISSUE 9: What provisions/attention should be taken for the possibility of `shell' bindings built on top of a generic binding?

Care must be taken to provide clear and logical mappings from the bound functions to their source in the functional interface standard. In general, one to one mappings provide such clarity. However, it is recognized that certain constraints of the programming language (such as number of parameters, etc.) as well as implementation considerations may suggest alternative groupings/splittings of functions. These alternatives should be used infrequently.

Reference ISSUE 10: How should standard functions be bound to a language?

Parameters should be bound rigidly in the order they appear in the functional interface standard description. Extra parameters, required by a language should follow the rule that input parameters must precede output parameters.

Reference ISSUE 11: Must strict conformance be followed in ordering of parameters, or should it be possible to change the order of the parameters bound to a given language from those presented in the functional interface standard document? For example, some languages may require that an output array parameter be accompanied by its length as an input parameter.

Strict conformance to the functional interface standard must be maintained in the definition of input and output parameters.

Reference ISSUE 12: Must strict conformance be followed in the definition of parameters as input and output, as defined in the functional interface standard document, or should it be possible to change the type of a parameter from input to output and vice versa?

Related semantic parameters in the functional interface standard may be combined into single syntactic parameters (such as records) when such grouping is obvious. It is suggested that any grouping evident in the functional interface standard be followed.

Alternatively, it might be better to design the interface with the intent of grouping elements and passing individual elements when binding to a language that does not support any grouping. With this approach, the grouping would be defined within the base design of the functional interface standard rather than being considered separately for each binding. "Ungrouping" is a mechanical operation, but grouping requires more consideration.

Reference ISSUE 13: Should the combination of related SEMANTIC parameters into a single SYNTACTIC parameter be encouraged?

The functional interface standard should be followed strictly when binding enumerated types to enumerated types in a language. When binding enumerated types to integers in a language, a consistent numbering scheme should be used. It is suggested that consistent criteria be used in the development of the functional description, since inconsistencies imply a run-time conversion. Often there is a natural ordering implicit in the meaning of the enumerated values (for example, LEFT, MIDDLE, RIGHT). Other schemes are to put the default first or to always put values that map to 'null' (i.e., =0) in the first position.

Reference ISSUE 14: Should there be a consistent numbering (ordering) of enumerated type members across the various language bindings?

If a language allows the definition of data types equivalent to, or subset of, some basic type, then any data type of the functional interface standard may be bound in different occurrences to different types in the programming language.

As an example, in Pascal a single data type from a functional interface may be bound to more than one subset of type integer.

Reference ISSUE 15: How should functional interface standard data types be bound?

Implementation-defined language types may be used if portability of applications within the language is not affected.

As an example, in Pascal type 'char' may be used.

Reference ISSUE 16: May there be TYPES which are implementation dependent?

In general, the standardized functions calls should be distinguishable from user-defined functions as long as the language allows this.

As an example, in Ada the package name distinguishes calls to the system facility from calls to user-defined functions.

Reference ISSUE 17: Should functions be easily identifiable in the applications code ('lexical differentiability')?

Abbreviations should be generated from the functional interface standard names in a consistent manner.

This provides a relatively straightforward method of mapping binding identifiers back to the functional interface standard.

One way of achieving this guideline is to eliminate unnecessary words.

Reference ISSUE 18: From what roots should binding identifiers or abbreviations be derived?

Due to differences in the practices of programmers as well as the constraints/characteristics provided for different languages, the concatenation character, if any, must be chosen separately for each programming language.

Reference ISSUE 19: How should abbreviations of the function names be concatenated?

A single approved abbreviation list should be used for all languages that have unrestricted lengths for identifiers. The BASIC and FORTRAN bindings have special considerations for identifier syntax, these considerations should be used for any other bindings developed for these languages or other languages that have similar identifier restrictions.

Reference ISSUE 20: Should the BASIC/FORTRAN bindings be considered in the development of the abbreviations list?

Abbreviations of function names should be derived from an approved list that contains a single abbreviation for each word. Either the single abbreviation, or the word in full, may be used in the binding.

Reference ISSUE 21: In languages which have no restriction on identifier lengths, how should abbreviations of the function names be derived?

Names of data types should be abbreviated in a consistent manner. However, names of data types are not constrained to the approved abbreviation list for abbreviations. Other identifying abbreviations and conventions may be used in a consistent way throughout the binding.

Reference ISSUE 22: Should bindings abbreviate the names of the data types in the same manner as functions (within a single language binding)?

When system facility data types are bound to different languages in a similar way, the identifiers to which they are bound should be similar.

Reference ISSUE 23: Should bindings abbreviate the names of the data types in the same manner as functions consistently across languages (excluding sentinel tags).

For readability, ease of maintenance, and to ensure completeness, all documents defining bindings to a functional standard should use a common schema (i.e., a common structure and a common set of contents) which is based on the functional standard itself, as the central point of reference for all bindings. This common schema should be such as to aid cross-referencing and to ensure that all relevant aspects of the functional standard are addressed by all bindings. The contents of a bindings document should address all language-related aspects of the binding, including mapping of functions, mapping of parameters, and binding-specific errors. To minimize revisions in binding documents following revisions of the functional standard. Also, they should not attempt to address issues (such as errors in performing the functionality) which are within the scope of the functional standard. Overdetailed references from the bindings documents to the functional standard should be avoided. The functional standards themselves, of course, should not attempt to address issues at the language binding level.

Reference ISSUE 24: What format (documentation structure) should the binding document follow?

The following are suggested as guidelines for specification of user-defined interfaces:

Put all the definitions for a single program's interaction into a single module definition. This simplifies compilation and facilitates semantic checking.

Use declarative statements to simplify the imperative definitions of procedures and avoid repetition.

Make the level of imperative statements match the functions supplied by the system facility.

Allow several imperative statements to be combined within a single procedure to simplify the calling programs. This may require the addition of test statements if there is a possibility of errors preventing the normal completion of a procedure.

This recommendation has added significance if the overhead of the procedure call is profound, e.g., if the application program and the supporting service are mutually remote. Even if this is not the case, procedure calls may involve data conversion overheads.

Exception handling might be more clumsy if successive actions are specified in a single procedure. If combining imperative statements is permitted, bindings should also be defined for the individual imperative statement.

Extending a programming language to provide access to a system facility carries certain risks, the principal one being a creeping inconsistency between the explanations in the programming language specifications and those in the system facility specifications.

Keep the facilities provided in one to one correspondence and define the semantics of the system functions in the system facility specifications only.

If new concepts are introduced in the programming language definition, they must be explained in terms of a mapping to underlying system facility functions. However, the introduction of new concepts and of new state variables should be avoided.

Language specifiers should consider the problem of subset or superset implementations of the system facilities. Such implementations may not work effectively with the host language extensions and it may be difficult or impossible to mix access through language extensions and access through procedure calls in the same program.

In general, the method of using embedded alien syntax within a programming language is not recommended. If it is required, the considerations for the design of the sublanguage are similar to those for the design of the module definition language (see Section 3.4.3), but the final definition of the escape mechanism is the responsibility of the language standards committee.

4 FUTURE DIRECTIONS

To date most programming languages have developed in splendid isolation, both from each other and from system facilities. The problems of interworking with system facilities or with other programming languages have not been taken into consideration. Indeed, there is little that any particular language committee can do on its own, since these issues require joint action by at least two committees.

The need for action is growing rapidly. At present, commercial application programs generally run in an environment determined by an operating system and including database systems and transaction processing monitors. Within workstations, system facilities may include complex man-machine interfaces, local databases and access to remote services. New applications involving parallel numerical computation or rule-based knowledge processing will require interworking with processes developed using different programming paradigms.

Sections 2 and 3 offer general and specific guidelines for overcoming the problems of incompatibilities, but their arbitrary selection within different system facility bindings could lead to unacceptable demands on users. For example, one could imagine having to process a program source text through several different pre-processors before being able to compile it.

One solution to the problem of overcoming incompatibilities is to build an intelligent system to handle it. The start of this process may be seen in Data Dictionary Systems (Information Resource Dictionaries) and in the development of Integrated Project Support Environments (IPSE's). Such systems may be able to offer more unified user interfaces, facilitate the management of system generation and control the compatibility of system components.

In general, the task of interfacing components would be much simplified if there were more precision within and more commonality between language specifications. In particular, there is a need for a common set of data types, common construction mechanisms (e.g., records, lists, arrays) and common interworking mechanisms (procedure calls, events, process synchronizations). The need for remote interworking between different hardware/software systems is an added imperative for action.

Since much of this section draws on the experience in the subject area of computer graphics, a summary of GKS (ISO 7942) is given, with particular emphasis on those aspects relevant to language bindings.

It should be noted that GKS will not be the only programming standard in the graphics area. GKS-3D is an extension of GKS to three dimensions. PHIGS is a work item which allows more sophisticated graphics workstations to be used. Each of those three systems is intended for application programmers. Another potential standard (the Computer Graphics Interface) will address interfaces supported by graphics devices and can exist in the form of a data stream or as a programming interface. This particular programming interface will be used by programmers building tools for application programmers.

'The Graphical Kernel System (GKS) provides a set of functions for computer graphics programming. GKS is a basic graphics system that can be used by the majority of applications that produce computer generated pictures'. (Quote from GKS Clause 0)

'The Graphical Kernel System (GKS) provides a functional interface between an application program and a configuration of graphical input and output devices. The functional interface contains all basic functions for interactive and non-interactive graphics on a wide variety of graphics equipment.' (Quote from GKS Clause 4.2).

GKS functions deliver/receive graphics data to/from a graphics device or set/inquire the internal GKS states which determine how the graphics data is to be treated. The definition of a GKS function includes:

An example of the definition of a GKS function is given in Figure 1.

REQUEST STROKE WSOP,WSAC,SGOP L0b

Parameters

In workstation identifier N

In stroke device number (1..n) I

Out status (OK,NONE) E

Out normalization transformation number (0..n) I

Out number of points (0..n) I

Out points in stroke WC nxP

References:

4.6.5

4.8.1

4.8.2

4.8.3

4.8.4

Errors: 7 GKS not in proper state: GKS shall be in one of the states WSOP, WSAC, or SGOP.

20 Specified workstation identifier is invalid.

25 Specified workstation is not open.

38 Specified workstation is neither of category INPUT nor of category OUTIN

140 Specified input device is not in REQUEST mode.

In the definition of a parameter of a GKS function, the data type, coordinate system, and range of permitted values are defined in clause 6.1 of GKS - see Figures 2, 3, and 4 respectively.

The data type can be a simple type, which is one of the following:

Alternatively, the data type can be a combination of simple types, thus:

For coordinate data, the relevant coordinate system is indicated:

Permitted values can be specified by:

In a language binding of GKS:

Following through with the example shown in Figure 1, specific instances from the Pascal, FORTRAN, Ada, and C GKS bindings are given in Figure 5.

Procedure GReqInput(

InputClass : GEInputClass;

WsId : GTWsId;

InputDeviceNum : GTInt1;

VAR Status : GEReqStatus;

VAR inputvalue : GRInput );

(* The constants are defined elsewhere *)

Type

GEInputClass = (GVLocator..GVString);

GTWsId = INTEGER;

GTInt1 = 1..MAXINT;

GEReqStatus = (GVStatusOK, GVNoInput, GVStatusNone);

GRInput = record

case InputClass : GEInputClass of

...

GVStroke: (NormTranStroke:GTint0;

Num : GTint0;

Points : GAPointArray);

only stroke record construct is shown

...

end;

GTint0 = 0..MAXINT;

GAPointArray = array[GTMaxPoint1] of GRpoint;

GRPoint = record

x,y : REAL;

end;

GTMaxPoint1 = 1..GCMaxpoint;

The Pascal GKS binding contains the following alternative binding for this function:

Procedure GReqStroke(

WsId : GTWsId;

StrokeDeviceNum : GTInt1;

VAR Status : GEReqStatus;

VAR StrokeMeasure : GRStroke);

with the additional data type -

type GRStroke = record

NormTranStroke : GTInt0;

Num : GTInt0;

Points : GAPointArray;

end;

SUBROUTINE GRQSK (WKID, SKDNR, N, STAT, TNR, NP, PXA, PYA)

Input: INTEGER WKID

INTEGER SKDNR

INTEGER N

Output: INTEGER STAT

INTEGER TNR

INTEGER NP

REAL PXA (N), PYA (N)

Gint - integer

Gfloat - floating point number

typedef struct {

Gfloat x;

Gfloat y;

} Gwpoint;

typedef struct {

Gint transform;

Gint n_points;

Gwpoint *points;

} Gstroke;

typedef enum {

GOK,

GNONE

} Gistat;

typedef struct {

Gistat status;

Gstroke *stroke;

} Gqstroke;

greqstroke (ws, dev, response)

Gint ws;

Gint dev;

Gqstroke *response;

There are alternative methods for binding this function in Appendix A of the C GKS binding for nonconforming C Compilers.

procedure REQUEST_STROKE

WS : in WS_ID;

DEVICE : in DEVICE_NUMBER;

STATUS : out INPUT_STATUS;

TRANSFORMATION : out TRANSFORMATION_NUMBER;

POSITION : out WC.POINT);

type WS_ID is new POSITIVE;

type DEVICE_NUMBER is new POSITIVE;

type INPUT_STATUS is (OK,NONE);

type TRANSFORMATION_NUMBER is new NATURAL;

package WC is new GKS_COORDINATE_SYSTEM(WC_TYPE);

type WC_TYPE is digits PRECISION;

NOTE: GKS_COORDINATE_SYSTEM is a generic package which defines an assortment of types that support each of the GKS coordinate systems.

The following issues do not have a solution or a resolution. They are intended to illustrate the pros and cons of various issues that occured during implementation of GKS bindings.

ISSUE #1: What should be the criteria for determining if the functional interface standard should be bound to a particular programming language? (Guideline 5)

Discussion: Some guideline must be imposed to determine when a binding may be done to a language. In general, only languages for which there are existing standards have been bound. However, there may be sufficient interest in binding the functional interface standard to a language for which a standard has not been currently adopted. The possibility of a 'Generic' Binding has been raised, which offers another solution to this problem.

Note: It is assumed that the appropriateness of a binding development effort to the language has been assured.

Alternatives:

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #2: To what event(s) should new versions of a binding be tied? (Guideline 8)

Discussion: Once a binding is accepted as a standard, the question arises as to when, if ever, consideration must be made to reviewing that binding and, perhaps, updating it.

Alternatives:

1 - Only when new versions of the language are developed.

2 - Only when new versions of the functional interface standard are developed.

3 - Only when both the language and the functional interface standard have changed.

4 - Neither 1 nor 2, but on its own five year cycle.

5 - When either the language or the functional interface standard have changed.

6 - Never.

Arguments:

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #3: How are 'real world' limitations to the standard taken into consideration? (Guideline 9)

Discussion: There are cases where many implementations of a language have chosen to be non-standard to reduce the resources consumed. As an example, many Pascal compilers have a limitation on the length of identifiers.

Alternatives:

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #4: How much of the 'spirit' of the language is taken into consideration when developing a binding? (Guideline 27)

Discussion: Multi-language shops and implementation peculiarities could require changes from or avoidance of certain standard capabilities of a language.

Alternatives:

1 - Use the 'full richness' of the language, as specified by the standard for the language, if applicable.

2 - Only bind to a minimal subset of the language.

Arguments:

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #5: For what types of programmers should the bindings be developed? (Guideline 28)

Discussion: This issue is similar to the preceding `full richness' issue. In addition, it impacts the amount and trueness of mapping of binding names and data types directly from the corresponding functional interface standard names and types. If knowledge of the functional interface standard is assumed, then its terminology should be used consistently. However, if only the language is known, perhaps more appropriate or easily recognized terms should be used. This issue actually is an attempt to determine the user community of the standard.

Alternatives:

1 - Assume knowledge of the functional interface standard.

2 - Assume expertise in the language, but not in the functional interface standard

3 - Assume neither.

4 - Assume both.

Arguments:

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #6: Should a generic binding (i.e., a single binding that can be used for many programming languages) be the only binding developed for the functional interface standard? (Guideline 28)

Discussion: A system facility committee might produce only a generic binding and require a preprocessor for each language to create appropriate statements for the target language.

Alternatives:

Arguments:

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #7: Should the development of a generic binding be supported? (Guideline 29)

Discussion: A generic binding can be presumed to be used in one of three ways:

Alternatives:

1 - Oppose development of all but language specific bindings for the functional interface standard.

2 - Support the development of a Generic Binding for the functional interface standard.

Arguments:

a. Pro 1 - less confusion in the market place.

b. Pro 1 - produces only verifiable implementations.

c. Pro 1 - most economical approach in terms of resource commitment.

d. Pro 2 - there is a well documented desire to have one.

e. Pro 2 - could standardize lowest common denominator in the functional interface standard.

f. Pro 2 - would maximize flexibility for implementors who want to take advantage of either.

g. Con 1 - if the work is done to develop a generic binding, why not take advantage of it?

h. Con 2 - there is no generic language standard yet.

i. Con 2 - would create possibility of two bindings for one language.

j. Pro 2 - no reason not to document a well used interface.

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #8: If the development of a generic binding is supported, should the development of more than one generic binding be supported? (Guideline 30)

Discussion: As shown in the discussion of Issue #4b above, there are three, and possibly more, methods for handling the multi-language environment.

Alternatives:

1 - No, a single generic binding should be enough.

2 - Yes, any number of generic bindings should be supported.

Arguments:

a. Pro 1 - there is the possibility that many request for generic bindings would develop otherwise.

b. Pro 1 - reduces confusion to have only one generic binding.

c. Pro 2 - no reason not to document a well used interface.

d. Pro 2 - If work has been done to develop a given generic binding, why not take advantage of it?

e. Con 2 - Could be difficult to verify program or package conformance.

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #9: What provisions/attention should be taken for the possibility of `shell' bindings built on top of a generic binding? (Guideline 31)

Discussion: When binding the functional interface standard to a specific language, there may be occasions when a choice must be made between two adequate methods of binding. Should the binders be careful to make the choice so as not to preclude the building of a `shell' for those in the multi-language environments?

Alternatives:

1 - None.

2 - The language bindings should not use facilities which cannot be layered with the generic binding.

Arguments:

a. Pro 2 - supports a known constituency.

b. Con 2 - capabilities of the generic binding are not known yet.

c. Pro 2 - Reduces the maintenance costs for implementors.

d. Con 2 - changes to the Kernel will have wide-spreading effects.

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #10: How should standard functions be bound to a language? (Guideline 33)

Discussion: For easy mapping back to the functional interface standard document, some consistent procedure must be defined for binding the standard functions. An investigation has been made into those standard functions which it is felt fall into a category which does not require one for one mapping into a binding.

Alternatives:

1 - bind one to one.

2 - bind one to many.

3 - bind many to one.

4 - bind many to many.

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #11: Must strict conformance be followed in ordering of parameters, or should it be possible to change the order of the parameters bound to a given language from those presented in the functional interface standard document? For example, some languages may require that an array, which is an output parameter, be accompanied by its length as an input parameter. (Guideline 34)

Discussion: New parameters, not described in the functional interface standard, must sometimes be added. Sometimes these new parameters are input parameters directly associated with given output parameters. Grouping of input parameters followed by output parameters is perceived by some as good software engineering, though it is changing the ordering from the functional interface standard document.

Alternatives:

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #12:Must strict conformance be followed in the definition of parameters as input and output, as defined in the functional interface standard document, or should it be possible to change the type of a parameter from input to output and vice versa? (Guideline 35)

Discussion: Some languages can return pointers to data areas in an efficient manner. Others handle structures efficiently.

Note: the following arguments actually center around the changing of input parameters to output parameters in the case of the C binding, where workstation id and segment name could be pointers assigned by the system instead of being assigned directly by the programmer.

Alternatives:

1 - Follow strict conformance in input/output.

2 - Change parameters depending upon the language constructs and philosophy.

Arguments:

a. Con 1 - doesn't necessarily use the full language capabilities.

b. Pro 2 - efficiency of implementation.

c. Pro 1 - programmer portability.

d. Pro 1 - consistency with the functional interface standard document and other bindings.

e. Pro 1 - may actually change the meaning of the function. given to generate the 'next number'.

f. Con 2 - the programmer will be lulled into a fake sense of security.

g. Pro 1 - all languages can handle this alternative.

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #13: Should the combination of related SEMANTIC parameters into a single SYNTACTIC parameter be encouraged? (Guideline 36)

Discussion: In some languages, certain information which is spelled out in the GKS functional description as a parameter is implicitly supplied by the language (such as the number of characters in a string, for FORTRAN 77). Also, there are certain functional interface standard entities which naturally fall into groups, as they are used together. These entities may be defined as separate items in the functional interface standard, but could be grouped into record structures in many programming languages.

Alternatives:

1 - yes.

2 - no.

Arguments:

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #14: Should there be a consistent numbering (ordering) of enumerated type members across the various language bindings? (Guideline 37)

Discussion: The language bindings currently being reviewed show no particular consistency of numbering enumerated type members. One suggestion is to follow a guideline in numbering any 'null' value as zero, then following the functional interface standard document order (the null-value rule).

Alternatives:

1 - Follow the functional interface standard strictly.

2 - Develop a consistent numbering which includes the null-value rule.

3 - Don't bother.

4 - As in Alternative 1 when binding to enumerated types, as in Alternative 2 when binding to integers.

Arguments:

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #15: How should functional interface standard data types be bound? (Guideline 38)

Discussion: For consistency, there may be a procedure for mapping functional interface standard data types to language data types. However, for languages with sophisticated data types, there may be a more flexible method.

Note: There is a recognized need for a consistent set of rules for matching data types between languages. This is an area under research by other ISO committees, and will be welcomed guidance for binding development.

Alternatives:

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #16: May there be TYPES which are implementation dependent? (Guideline 39)

Discussion: Some languages provide the facility to define data types which are implementation-dependent (e.g., 'generic' in Ada). For example, a binding may require 16 bits precision in integers; this does not preclude using a 32 bit integer. These types conform to the language standard, but their definitions in terms of the base types of the language may differ.

Alternatives:

1 - Yes, where portability of applications within the language is not affected.

2 - No.

3 - Yes, without worrying about portability.

Arguments:

a. Pro 1,3 - Uses the 'full richness' of the language.

b. Con 3 - The whole point of a standard language binding is to provide portability.

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #17: Should functions be easily identifiable in the applications code ('lexical differentiability')? (Guideline 40)

Discussion: There may be a need to distinguish the standard functions from applications functions.

Alternatives:

1 - Yes

2 - No

3 - Yes, unless language considerations make it unnecessary.

Arguments:

a. Pro 1 - Good programming practice.

b Pro 1 - maintainability.

c. Pro 2 - The selected sentinel characters may have been already used in the implementation.

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #18: From what roots should binding identifiers or abbreviations be derived? (Guideline 41)

Discussion: In order to be consistent in naming the functions of a binding, there must be a set of words from which to determine abbreviations. Some of the GKS function names have what may seem to be `unnecessary' words (TO, OF). Some of the functional interface names may seem to be unnecessarily complex.

Alternatives:

1 - None (take each language on an individual basis).

2 - Map abbreviations one-for-one from function names and not eliminate any words.

3 - As with 2, but eliminate unnecessary words, in a consistent manner.

Arguments:

a. Con 1 - Transportability problems.

b. Pro 1 - Readability.

c. Con 2 - Would produce a multitude of abbreviations.

d. Pro 2,3 - Transportability.

e. Pro 2 - Good reference back to the functional interface standard document.

f. Con 3 - Poor mapping to functional interface standard document (possible change of meaning).

g. Pro 3, Con 2 - eliminates words like `to', `of', etc.

i. Con 1 - Makes each language as hard to bind as all the others; no benefit from experience.

j. Con 2 - Doubtful that this can be done for all languages.

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #19: How should abbreviations of the function names be concatenated? (Guideline 42)

Discussion: It is possible to have identical names across similar languages. However, the `spirit' (or usual practice) of some languages is to use case distinctions or underscores to concatenate words within identifiers.

Alternatives:

1 - Use no special characters.

2 - Use special, language-dependent characters when available.

3 - Use case distinctions when available.

4 - Use special characters and case distinctions (2 and 3).

5 - Decide on a language by language basis.

Arguments:

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #20: Should the BASIC/FORTRAN bindings be considered in the development of the abbreviations list? (Guideline 43)

Discussion: Since these bindings have different restrictions than those to the other languages, the consideration of them and their abbreviations could be a determining factor when attempting to develop consistent abbreviations for other bindings.

Alternatives:

1 - yes

2 - no

3 - Only when binding to languages with naming restrictions similar to BASIC and FORTRAN.

Arguments:

a. Pro 1 - consistency across all languages.

c. Pro 1,3 - Promotes program/programmer portability.

d. Con 3 - what similar languages?

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #21: In languages which have no restriction on identifier lengths, how should abbreviations of the function names be derived? (Guideline 44)

Discussion: It is hoped that each function from the functional interface standard may be abbreviated in some consistent manner across languages.

Alternatives:

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #22: Should bindings abbreviate the names of the data types in the same manner as functions (within a single language binding)? (Guideline 45)

Discussion: In some languages, it is allowed to have identical names for functions and for associated data types.

Alternatives:

1 - Use names of 8 characters or less.

2 - Use the full functional interface standard data type names.

3 - Use names identical to the functions.

4 - Be consistent within the language.

Arguments:

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #23: Should bindings abbreviate the names of the data types in the same manner as functions consistently across languages (excluding sentinel tags). (Guideline 46)

Discussion: For similar languages, similar data types may have the same names.

Alternatives:

1 - yes, where practical.

2 - no.

Arguments:

a. Pro 1 - consistency, easier for programmer portability.

b. Con 1 - hard to determine whether data types are really similar.

------------------------------------------------------------------------------------------------------------------------------------------------------------

ISSUE #24: What format (documentation structure) should the binding document follow? (Guideline 47)

Discussion: With multiple bindings being developed, the need may exist for similar formats for all.

Alternatives:

1 - Each one should be formatted individually.

2 - Follow a single format as closely as possible.

Arguments: