381

Graphics Language Bindings - The what and why

Madeline Sparks

1. Introduction 2. Issues When an eagerly awaited standard is developed for a functional area such as graphics, the community of vendors and users heave a vast sigh of relief and begin to actively attempt to use it. Immediately, however, the potential user/implementor could be faced with a difficult problem: the required func- tions have been effectively defined in the body of the standard, but how does he access these func- tions in his world of higher level applications pro- gramming? The answer lies in the use of standard access mechanisms to the functions from the pro- gramming languages. These access mechanisms are called language bindings.

With earlier ‘de facto’ graphics standard each implementor developed his own set of pro- grammer interface calling sequences and parame- ters, leading to a plethora of individual, fairly diverse approaches to defining the functions to the programmer. Applications code written for one implementation of such a graphics system was very rarely portable to another implementation. Pro- grammers who thought they understood the basic graphics concepts still found it difficult to move to a different vendor’s interpretation of the same functional system.

A standard that defines functions applicable to many applications areas should be accessible from many programming languages. So, standard bindings are being developed for each emerging graphics standard.

Ten binding standards are being developed internationally during 1985-1986, for graphics alone. This paper discusses some of the problems that have been solved during the development of those programming language bindings. The docu- mentation of these issues is intended to help prepare potential bindings generators by briefly describing some of the pricipal decisions that went into the development of the graphics bindings.

System Development Corporation 48 10 Bradford Blvd. Huntsville, AL 35805 U.S.A.

Within the International Standards Organization (ISO) the TC97/SC21/WG2 Language Binding Rapporteur Group (LAB) is responsible for all language bindings of the graphics standards being developed by WG2 (Graphics Standards).

The first Graphical Kernel System (GKS) binding (to FORTRAN) is technically complete. The group identified some basic binding issues that pertain to all programming languages. These issues fall into the following categories: - Goals andScope - Naming/Abbreviations - DataTyping - Multi-Language Environment Considera-

t iOnS

- Format of the Document - ErrorHandling - Functions and Parameters

A specific description of the issues may be found in “The GKS Binding Generic Issues List” (reference I), which includes some argumentation and an indiction of the agreed resolution for each issue.

2.1. Coals and Scope A first consideration is the circumstances sur- rounding the initiation of the work on a binding to a programming language. Should the sole driving force be the demands of the user community? How is a binding developed if no standard exists for the language? (There’s a C community eager for a standard graphics interface, but currently no national body of international C language stan- dard.) Where are the resources found to do the development work? What should be the con- siderations or constraints, if any, required of a binding being developed to an IS0 standard, if a national body language standard for that language is Merent? (IS0 Pascal has two levels, with con- formant arrays; ANSI has one level, without con- formant arrays.)

For a binding to be useful, timely and dur- able, there must be an existing or emerging language standard before work on the bindings

North-Holland Computer Graphics Forum 4 (1985) 381-392

388 M. Sparks Graphics Language Bindings

begins. De facto bindings to non-standard languages may be published as technical reports, but only standard languages may be considered for standard bindings. National differences must not be allowed to impose artificial constraints.

Other areas of concern involve the formal mechanisms necessary to interact between two or more standards-making bodies. Obviously, liais- ons to and from the language committees must be carefully set up and maintained, both within national bodies and internationally. These liaisons work both ways. The language committee members, concentrating on improving the next ver- sion of their languages, are working on future ver- sions of the language, and, of course, want the newest mechanisms used in the binding. They are recognized experts in their languages, Procedures (reference 2) are followed to allow a communica- tion channel to be set up so that the needs of the graphics community can be fed back to the language committees, along with ideas about necessary and useful future language constructs. At the same time, this liaison ensures the proper “flavour” of the language in the binding. Another important liaison role is that of checking for vali- dity.

After a language is selected for binding and liaisons have been set up, the language-specific problems must be solved. An important issue is determining the extent of the language facilities that should be used in the binding. Should the “full richness of the language” always be a factor, or should consideration also be given to the porta- bility of programmers between languages? This type of problem is a. ticklish one; the binding developers find themselves juggllng many impor- tant factors.

Some languages, such as Ada, have unique capabilities (such as multi-tasking features and exception handling) that actually provide more than the functional specification requires; should these be used, or should the binders stick to the “letter of the law”? Other languages, such as FORTRAN, simply cannot practically provide all the functional requirements in a one-forsne way. An example is the requirement in GIG for the programmer to be able to retrieve from the GKS implementation a list of related, but heterogene- ously typed, graphical data items. This translates into an extremely long list of parameters if bound to a single call in FORTRAN; Pascal, however, can group the data into a single record. So, may the binders break the single GKS function into

many subroutines in the FORTRAN binding, but keep it a single procedure in the Pascal binding? In general terms, is similarity between bindings (for programmer portability) more important than the use of the full language capabilities (for experts in the language)? Who is the “audience” of the binding?

Obviously, there is no one simple solution to this type of problem. A trade-off must be made between maintaining similarity among all bindings of a functional specification and reflecting the specific features/limitations of the languages. Gen- eral attempts should ensure a measure of similar- ity; however, on the whole, language capabilities should be utilized whenever suitable.

Another set of problems is introduced by the subject/leveled language standard. An example is Subset FORTRAN, a part of the current FOR- TRAN standard, which provides a vehicle for upwards-compatibility from FORTRAN ‘66 to full FORTRAN. As such, it is a potential language for GKS applications, so an appropriate language binding had to be developed. However, the res- trictions of this minimal language put severe limi- tations on the data-type available. In every case where subsets to a standard exist (PL/I is another) or where older versions of the language are still being widely used, decisions have to be made con- cerning the amount of compatibility maintained between the various versions of the bindings. In the case of Subset FORTRAN, this was done by the definition of parallel subrouting calls for those functions that had character parameters. For IS0 Pascal, with two levels, international bindings for both levels were developed.

An associated problem is the recognition of the many compilers that impose more or require less restrictions than those found in the standard. As an example, although the current Pascal stan- dard allows 32 character length identifiers, many micro-hosted Pascal compilers restrict identifiers to 6 characters. The dilemma is whether to bind to the “real world’’ or to the standard. The latter may result in a binding of limited use. Just how much ef€ect should these “real world” require- ments have on the binding? The juggling act in this case is between the “right” way, which says to bind to the language standard, and the “just” way, which says let’s use what we know about what’s happening in the real world. In general, the extensions/limitations have been acknowledged, but no attempts have been made to provide stan- dard b i n e g s to those extras. In the specific case

M, Sparks J Graphics Language Bindings 389

of the Pascal micro environment, an appendix has been defined that contains suggested alternative ways of implementing the binding in a micro environment.

2.2. Naming/Abbreviations The first, and most obvious binding attribute seen by the user is the function names. Perhaps one would think that the selection of characters to represent a semantically defined function would be easy. However, the binders found that many issues emerged from this one, seemingly simple task. The first GKS language binding developed, to FORTRAN, posed an immediate problem because of that language’s restriction on the length of external names. Ideally, names should be read- able, pronouncable, and meaningful. However, six characters can be used to provide any number of acronyms, most of which are not pronouncable. From what roots then should the binding names be derived? Should the GKS functions names, sometimes made up of five or six words, be mapped one-for-one to a FORTRAN acronym? Or should something descriptive but not so care- fully derived from GKS be used? It was deter- mined that the GKS names were important enough that all mappings should be from them to some subset of characters. Some words, like’“T0” and “FROM” were mapped to “null”; others were combined to map to a single letter. A fairly com- plex naming algorithm was devised and carefully documented in the FORTRAN binding, so users could learn the mapping method.

It is easy to recognize the importance of “lexical differentiability” (the distinguishability of GKS functions within the applications code). But, how is this accomplished? If a sentinal character is used, what character or characters? Are special characters and case changes used when appropri- ate? (The chosen solution of reserving the letter “G” for FORTRAN GKS names leaves only 5 characters to work with for the rest of the names!) The features of the s p d c language should be used if appropriate. For example, Ada, has the packaging concept that provides “lexical differentiability”.

Another general naming problem that arises is: should an attempt be made to use the same names, and abbreviations for GKS names, across similar languages? Immediately one must define “similar”. The problem was resolved by the development of a common abbreviation allowing names of more than 6 characters to be drawn.

As can be seen, many problems exist in determining the correct set of characters to be used to represent a function. A general solution for these problems may be found in the approved abbreviation list, and is evident in the similarities found between the names chosen for the Pascal, Ada, and C GKS bindings.

23. Data Typing While the process of selecting the names to be used in program texts is a large part of the work involved in building a language binding, another set of problems requires equivalent effort; the typ- ing of the GKS data structures within the scope of the language. The GKS functional specification defines structured data types, including ENUMERATION data types for the specification of a small set of mutually exclusive choices, a RECORD data type for the logical grouping of heterogeneous primitive data types, and a POINT data type specifically designed to represent two- dimensional data. While it is a relatively simple matter to map these data types one-for-one into structured languages such as Ada and Pascal, older languages, such as FORTRAN, pose si@cant problems of translation and interpretation.

It is evident that even with the restricted typing available in FORTRAN. several interpreta- tions are possible. A section of the GKS FOR- TRAN binding carefully describes the way the GKS data types are converted to FORTRAN data types. A different problem exists with the struc- tured languages; although the record structures available in these languages map nicely with the GKS data structures, the question remains whether these data structures should be similar throughout the Pascal;C, and Ada GKS bindings.

File access mechanisms present a problem for every programming language. Pascal, FOR- TRAN, Ada, and C all handle files in different ways, and run on operating systems with diverse methods of file manipulation. The GKS functional specification defines an error file name used to access a file for error logging. The binders must decide whether this functional entity represents an already open file, a logical unit number, a closed file that must be opened, or simply a string of characters representing an implementation’s partic- ular file characteristics. Consequently, due to the inherent dependencies programming langauges have on the operating system environment, some data types and values have to remain “implementation-dependent” with respect to the

390 M. Sparks 1 Graphics Language Bindings

environment, with corresponding portability res- trictions.

Some languages have data typing facilities that return pointers to internal structures to the programmer. This method implies that the appli- cations programmer is allowed access to imple- mentation data structures. Is taking advantage of this language-specific capability a betrayal of the “spirit” of the functional specification? Or is the decision NOT to use this capability a denial of the “spirit” of the programming language? This sticky problem was resolved for G U by the decree of WG2 that parameters defined as “input” parame- ters in GKS must be input parameters in the bind- ings.

2.4. One-to-one vs One-to-Many Mapping If the assumption is made that all functional specification parameters are bound one-to-one with procedural parameters in the binding, parameters may result, such as the “number of characters” in a TEXT string when FORTRAN CHARACTER is used to type the string. Also, languages such as C have pointer types that may be assigned by the implementation and passed back to the programmer, instead of being sent to the implementation by the programmer as in FORTRAN. The binders have decided to elim- inate redundant parameters, but to stick closely to the GKS definition of input and output parame- ters.

A similar area of uncertainty lies in the combining and dissolving of functions in the bind- ing. When the initial FORTRAN binding of GKS was developed, it was found that using the one-to- one approach for binding GKS functions to FOR- TRAN subroutines created some subroutines that had more than 13 parameters. The solution was to break these subroutines into several subroutines, in a logical manner. In other places, GKS assumes the existence of dynamic memory alloca- tion; consequently, FORTRAN subroutines had to be defined to return a single programmer specified entity, rather than an entire, dynamically sized array. Was this changing the functionality of GKS? New utility routines had to be added to handle the packing and unpacking of dissimilar data; was this adding functionality to GKS? For both questions, the binders decided the advantages outweighed the disadvantages.

2.5. Error Handling Although the functional specification may define the error conditions resulting from each function, language and implementation specific errors must be accounted for in the binding. What is the minimum information required for all error mes- sages? Is the content of the error message “stand- ardized“? Certainly, for large systems running on megacomputers, access to voluminous information may be a desirable attribute of the error handler; micro-hosted implementations, on the other hand, may prefer to supply only an abbreviated string, or even simply an integer code. Modem languages such as Ada allow for exception handling, so the binders must decide how the binding specifies if. and when, this capability may be used.

A group of langauge-specific error numbers are assigned for each GKS language binding. All that is required of an implementation is the error number, but no limitations are put on the amount of additional information that may be produced by the implementations.

Unfortunately, vestiges of FORTRAN thinking are still obvious in the ideas and mechan- isms specified in the GKS document. Therefore, the type of error processing defined within GKS does not allow exception handling as a default error mechanism.

26. Multi-language Environment Although the majority of language binding work is aimed at to developing separate bindings to single programming languages, some implementors and users feel it is necessary to access GKS functions from more than one language, within a single implementation. This type of environment intro- duces its own set of issues. One approach to pro- viding for a multi-language environment is to develop a single, “generic”, binding (looking much like a FORTRAN Subset binding. How would this single binding be used: would it be interpreted by a preprocessor, used as a lowest common denominator, or serve as a basis for a set of (non- standard) shell routines? Could there be more than one generic binding? The programmer may then possibly be faced with selecting from more than one “standard” binding for a given program- ming language.

The possible existence of a “generic” bind- ing may impact the development of the separate language bindings. As an example, when deter- mining data typing in Pascal, conformant arrays could be used when convenient, but should they be

M. Sparks / Graphics Language Bindings 39 1

avoided, owing to the problems that most certainly would occur in mapping conformant arrays, through a “shell”, to a FORTRAN implementa- tion?

Efforts to date have been completely centred on single language bindings and these questions remain unanswered.

2.7. Format of the Document At first glance the physical format of the binding document may seem less important than the more technical issues. However, more than one binding could either follow a single format, or a different format could be chosen, one that matches the assumed constituency of the language. A FOR- TRAN programmer in the throes of building a GKS implementation may be rather uncomfortable interpreting a document written in the “spirit of C”?

The physical relationship of the finding documents to the functional specification is another area of concern. If the bindings are an integral part of a standard that contains both the bindings and the functional specification, some difficulty may occur when adding future bindings independently of the functional specification. On the other hand, if the bindings are separate stan- dards; then the interrelationship between the bind- ings and the functional specificaton must be care- fully preserved; a modification to the functional specification may require all bindings to be changed.

These “binding” binding problems have been resolved for GKS by the decision to package all GKS bindings together as a separate standard. The first binding (FORTRAN) is always provided with the GKS functional specification. A single, comprehensive format has been agreed for all bindings; in this way, similar information may be found in each binding in the same place.

2.8. Liaisons Of major importance is the establishment and maintenance of active liaison with the international language committees. The GKS binders have been fortunate to include members of the FORTRAN, Pascal, and Ada committees at their meetings.

3. Future Bindings The issues discussed here have addressed the prob- lems, and some solutions, that have resulted from the development of language bindings for GKS.

However, a far-reaching decision has been made by the binders: bindings for future graphics stan- dards will be built “on top of’ the GKS bindings. This means that once the major problems have been resolved for a language binding of GKS, they will not be reopened for other graphics bindings. This common set of guidelines has been the result of long hours of hard work and compromise dur- ing the past four years; a solid base for future work has been laid.

Of course, it is realized that each new func- tional standard may yet pose new problems. One example of the issues still to be resolved is the sim- ple question of how the “3” for the additional functions in GKS-3D is added to the FORTRAN GKS names, most of which are already six charac- ters long. Much work remains to be done.

4. Conclusion Language bindings are being developed along guidelines designed to provide required and desired portability. Since current language stan- dards are used as a baseline portability between hardware configurations is achievable wherever standard-confonning compilers are available. Application program portability is achieved between standardconforming implementations, through the mechanism of a single standard bind- ing for each language. The programmer can also move easily from one implementation to another, because of this single binding approach. And, when the programmer changes languages, the intentional similarities of the different language bindings help him retain his expertise with minimum relearning.

Determining the appropriate method for accessing a functional specification from a specific programming language is not a simple matter. Issues of portability are driving factors, as well as individual language problems (when a language’s special capabilities may be used in a unique way). The international binders charged with developing the graphics standards language bindings have identified the generic issues and resolved them in a manner that will attempt to meet all the stated cri- teria.

5. References All references are IS0 TC97/SC21/WG2 internal documents. Copies may be obtained by writing the author.

392 M. Sparks Graphics Language Binding

( 1 ) “The GKS Binding Generic Issues List”, (3) “GKS Abbreviation list”, LAB Rapporteur LAB Rapporteur Group. Group.

(2) “Procedures for the Promulgation of Language Bindings”, LAB Rapporteur Group.