Date: Fri, 01 May 1998 01:33:15 +0100 From: Keld Simonsen Subject: (SC22WG15.1269) LIS paper ISO/IEC JTC1/SC22/WG15 N768 Language Independent Specification techniques Source: Keld Simonsen Date: 1998-04-24 Action Item: 9705-23 Introduction This paper describes a number of ways to do Language Independent Specifications (LIS). It is intended for use in determining how POSIX LIS specifications would be done. The methods include LID/LIPC, IDL, and some not formalized techniques. An example is to be given with each of the techniques. The job of doing LIS can be separated in 2 areas, one is the definition of APIs with the interface and semantics, the other is definition of datatypes for one or more APIs, which may contain complicated structures. An API is here defined as a "Application Programming Interface", and that is then defined as a single function or procedure or program. In some other contexts an API is taken as a set of functions or the like, this is here called an "API set". An issue for the binding is the capabilities of the languages that will do a binding to the LIS. Some languages are advanced and have for example object oriented methods, parallel execution and exception handling, while others do not have composite structures or pointers. To be able to provide as broadly applicable Language Independent Specification it is recommended to provide interfaces with as simple datatypes as possible. For parameters that lend themselves to pointers in some programming languages, it is recommended just to have an implementation-defined type, and then the actual language binding could bind that to the appropriate type of the language. This may be a string to identify a structure in one language, and a data structure in another language, and a pointer to a structure in yet another language. For functionality where use of more advanced language capability is very natural for some languages, it is recommended to have multiple interface descriptions for the same functionality, one with the simple data types, and one with the more complex datatype. A language binding then should chose one of these specifications to bind to. These different versions of a functionality are called "API versions". Some programming languages do not have a return value for its interfaces, while many languages do. It is recommended always to denote a return value, and also name it, perhaps with the name of the interface. Then the programming languages without return value capability can refer to the named output parameter, and the languages with the return value capability can just refer the return value. To facilitate short bindings it is recommended that Language Independent specifications be written with section numbers identifying each API version. The language binding can then do the binding by just specifying this section number and then the name and parameters for the API binding. The LIS for a set of datatypes is an issue, for how to economically specifying this in a language independent manner, so that a reference like a C/C++ include directive can be used. LID/LIPC LID (Language Independent Datatypes) ISO/IEC 11404 and LIPC (Language Independent Procedure Calls) ISO/IEC 13884 are standards made by SC22/WG11. They are kind of Pascal/Modula/Ada in style. Example: procedure setlocale(out category: integer, in localename: string) returns locale. IDL IDL (Independent Definition Language) is defined by SC21 in ISO/IEC 14755. It is in a C style. locale setlocale(const int category, const string localename); Non-formalized One way of doing LIS is done in ISO/IEC CD 14651, the sorting standard. It builds on experience from IBM. It does not use formal declarations of data types and procedures. Procedure: setlocale Parameters: 1. category, input parameter 2. string, input parameter 3. locale, output parameter Half formalized A way of doing a half-formalized LIS specification is by naming the parameters and giving the result a name, but leaving out the actual types, and let that be defined by the binding. locale setlocale(category,localename) The status in/out of parameters could also be specified. Discussion Language independent specification is a layer of abstraction over what the normal user of the standards are expecting. Users of the programmer type then may have problems in using the specifications. There may be a preference for IDL over LID/LIPC as the C style notation is more readily understood by programmers. To be able to do as many bindings as possible the more informal specification technique may be preferable. In the case of POSIX specifications the intended range of bindings could be taken into account and the more formalized binding techniques could then make an easier way and more readily understandible (for programmers) technique. A technique combining the advantage of broad application of the unformalized technique with the more programmer-oriented syntax of the formalized techniques could be developed.