AdaIC Available Ada Bindings Report - 1996
SECTION 1: Introduction
In This Section: 1.1 Background 1.2 Purpose of this document 1.3 Report Organization 1.4 Definitions 1.5 Table of Available Ada Binding Products
1.1 Background To further the growth of Ada, it is important that Ada applications be able to access whatever resources an end user will wish to control. This frequently requires Ada bindings to other standards and protocols that control such resources. In general, a software standard defines a set of services that can be provided to an application and it defines an interface through which those services can be accessed. In order for an Ada program to use these services, there must be a definition of the interface expressed in terms of the Ada language. That definition is the Ada binding to the standard. These other standards may be formal standards, de-facto standards, or commercial products that have become widely available. Sometimes a binding effort may take place as part of a formal standardization program - with public input and representation from both the Ada community and the community most interested in the standard. At other times, a particular organization or company may write a binding only for a particular product, Ada compiler, or application, etc. The Department of Defense (DOD) and the Ada Joint Program Office (AJPO) have an interest in the evolution of standards; major standards bodies involved include the American National Standards Institute (ANSI), the Institute of Electrical and Electronics Engineers (IEEE), and the International Organization for Standardization and International Electrotechnical Commission (ISO-IEC). As indicated above, a "binding" is essentially conceptual - a definition. The user still needs to be able to obtain a product that implements the binding. Typically, the implementation of the bindings is provided by the same vendor as the implementation of the standard. Among the caveats to be noted in using this information is that the way in which a binding is designed can affect the portability and reusability of the Ada application that uses it. It should be clearly understood that this report does not address issues of portability and reusability. Users will have to evaluate both the binding itself and any binding product in order to ensure that they meet the needs of a given project. Also, DoD use of the Ada programming language does not imply in any manner that the DoD endorses or favors any commercial Ada product. 1.2 Purpose of this document The purpose of this document is to assist readers in selecting standards and bindings that are suitable for their work. The editors have attempted to provide material that assists readers in making this selection while remaining fair and even-handed in the descriptions. The responsibility to make the selection from alternatives rests with the reader; the editors have provided material to support the reader's decision, not to make the decision for the reader. 1.3 Report organization This report is divided into five major sections, including this introductory section of the standards and bindings treated in this article. The second section briefly describes software and other softcopy information available from software libraries. The third section list various Ada bindings on the AdaIC's Internet host and other repositories. The fourth section is a listing of vendor products. The guest editor is responsible only for the contents of the first section. Information in the second section is provided by the software libraries; information in the third section information in the fourth section is provided by vendors. Section 2 describes the history and status of the various standards and bindings. The individual subsections were written by guest authors. If more than one standard exists, it explains the relationships and differences among them and provides background information to aid a reader in making intelligent selections. In particular, if there are competing standards, the section should assist a reader in selecting one for a particular job. This section may include notes on the availability of conforming products as well as commenting on detailed documentation describing the standards. When appropriate, historical work is briefly described. Section 3 provides the reader with information on other standards and specifications for which Ada bindings are available. This list was generated after searching repositories and vendor product lists. Many of these standards and specifications are located on the AdaIC Internet host. Section 4 provides information on the various Ada bindings available on the AdaIC's Internet host and other repositories. The majority of the bindings in this section can be downloaded at no charge from the AdaIC host (sw-eng.falls-church.va.us). Section 5 provides information about commercially available bindings products. Information in this section was provided by vendors and collated by the AdaIC. It has not been verified, and neither the editors nor any of the collaborators should be held liable for its correctness or completeness. Further, it should be noted that with continuing developments, it is almost certain that some information has been superseded, and more products and services are available than are listed here. The AdaIC is always seeking word of changes and additions to the information given here. Appendix A provides descriptions of those standards for which no Ada binding products or resources were identified. Appendix B contains information on the following repositories and software libraries: the AdaIC's Internet host, Asset Source for Software Engineering Technology (SAIC/ASSET), Defense Software Repository System (DSRS), Electronic Library Services and Applications (ELSA), Public Ada Library (PAL) and the Reuse Information Clearinghouse's (ReuseIC) Internet host. 1.4 Definitions In order to make the treatment more uniform in the various sections, we have asked editors to make careful distinctions among various terms that are often confused or misused. First, we need to be careful in making the distinction between a specification and a product that implements the specification. Specification: Document describing a set of services that can be provided to another user or program. In this context, the specifications are usually provided by some group that is chartered for the purpose of developing and documenting the specification. Sometimes the specification is defined in terms of a specific programming language. In recent years, though, there has been a trend toward defining specifications in a manner that is independent of any particular language. In these cases, one must also define bindings to the various programming languages that are expected to use the services described by the specification. Product: Piece of software that implements a specification. In our case, products are typically provided by vendors who sell them commercially. Occasionally, they exist in the public domain. The next important distinction describes the type of interface provided by the product to permit application programs to access the services described by the specification. Broadly speaking, there are two types of interfaces: implementations and bindings. Implementation: Describes the form of interface where the product or a substantial portion of the product is implemented in the same language as the application program. This permits the application program to use the interface by compiling those portions of the product along with the application program. This form of interface is often found in layered reference models where the layers that are closest to the application program interface are written in the same language as the application. Binding: Describes the form of interface where the product is implemented in a different programming language than the application but exports an interface suitable for the desired programming language. In the case of Ada, we often find that the product is implemented in C but exports a set of procedures that may be called by an Ada program. Unfortunately, the term binding is also used in a more general sense to subsume both of the cases described above. Furthermore, the word binding is often used to describe both the specifications for the interface and the product that implements the interface. Binding specifications can be characterized in various ways: as thick or thin; and as direct or abstract. Thick/Thin: Bindings are sometimes described as "thick" or "thin". (These terms should not be confused with "direct" and "abstract" - see below.) Thickness and thinness refer to the method of specifying the semantics in the specifications document. A thick binding combines descriptions of both the syntax and the semantics provided by the binding. When referring to a thick binding, a user would probably refer only to the binding specification and not have to look at the language-independent functional specification. A thin binding specifies only the syntax of how a particular programming language can access a particular service. The reader of a thin binding would have to look at another document, the language-independent functional specification, to determine the semantics associated with the various syntactical constructions. Direct/Abstract: Concept is often confused with thick/thin. If a language binding generally provides direct access to the functionality of the specification via procedure calls and parameters, then the binding may be called "direct". If, on the other hand, the binding repackages the functionality to exploit the particular characteristics of the language, it may be called "abstract". Access to POSIX pthreads is an interesting and current example. If the standards-writers provide direct Ada procedure calls to create, synchronize and destroy POSIX pthreads, then this will be a direct binding. If, on the other hand, POSIX pthreads are equated to Ada tasks and the pthreads are implicitly manipulated via the language-defined tasking functions, then the binding will be abstract. Finally, we must be very careful to use the word standard appropriately. Standard: The term standard is used only to describe specifications that have completed the formal standardization process by an organization that has the legal authority to create standards. Specifications that have broad industry acceptance, but lack a formal standard may be termed "de facto standards". Specifications that are in a draft stage and have not yet completed the standardization process may be called "draft standards" or "proposed standards." Previous Section Table of Contents Next Section Keyword Search
In general, a software standard defines a set of services that can be provided to an application and it defines an interface through which those services can be accessed. In order for an Ada program to use these services, there must be a definition of the interface expressed in terms of the Ada language. That definition is the Ada binding to the standard. These other standards may be formal standards, de-facto standards, or commercial products that have become widely available.
Sometimes a binding effort may take place as part of a formal standardization program - with public input and representation from both the Ada community and the community most interested in the standard. At other times, a particular organization or company may write a binding only for a particular product, Ada compiler, or application, etc. The Department of Defense (DOD) and the Ada Joint Program Office (AJPO) have an interest in the evolution of standards; major standards bodies involved include the American National Standards Institute (ANSI), the Institute of Electrical and Electronics Engineers (IEEE), and the International Organization for Standardization and International Electrotechnical Commission (ISO-IEC).
As indicated above, a "binding" is essentially conceptual - a definition. The user still needs to be able to obtain a product that implements the binding. Typically, the implementation of the bindings is provided by the same vendor as the implementation of the standard.
Among the caveats to be noted in using this information is that the way in which a binding is designed can affect the portability and reusability of the Ada application that uses it. It should be clearly understood that this report does not address issues of portability and reusability. Users will have to evaluate both the binding itself and any binding product in order to ensure that they meet the needs of a given project. Also, DoD use of the Ada programming language does not imply in any manner that the DoD endorses or favors any commercial Ada product.
1.2 Purpose of this document The purpose of this document is to assist readers in selecting standards and bindings that are suitable for their work. The editors have attempted to provide material that assists readers in making this selection while remaining fair and even-handed in the descriptions. The responsibility to make the selection from alternatives rests with the reader; the editors have provided material to support the reader's decision, not to make the decision for the reader. 1.3 Report organization This report is divided into five major sections, including this introductory section of the standards and bindings treated in this article. The second section briefly describes software and other softcopy information available from software libraries. The third section list various Ada bindings on the AdaIC's Internet host and other repositories. The fourth section is a listing of vendor products. The guest editor is responsible only for the contents of the first section. Information in the second section is provided by the software libraries; information in the third section information in the fourth section is provided by vendors. Section 2 describes the history and status of the various standards and bindings. The individual subsections were written by guest authors. If more than one standard exists, it explains the relationships and differences among them and provides background information to aid a reader in making intelligent selections. In particular, if there are competing standards, the section should assist a reader in selecting one for a particular job. This section may include notes on the availability of conforming products as well as commenting on detailed documentation describing the standards. When appropriate, historical work is briefly described. Section 3 provides the reader with information on other standards and specifications for which Ada bindings are available. This list was generated after searching repositories and vendor product lists. Many of these standards and specifications are located on the AdaIC Internet host. Section 4 provides information on the various Ada bindings available on the AdaIC's Internet host and other repositories. The majority of the bindings in this section can be downloaded at no charge from the AdaIC host (sw-eng.falls-church.va.us). Section 5 provides information about commercially available bindings products. Information in this section was provided by vendors and collated by the AdaIC. It has not been verified, and neither the editors nor any of the collaborators should be held liable for its correctness or completeness. Further, it should be noted that with continuing developments, it is almost certain that some information has been superseded, and more products and services are available than are listed here. The AdaIC is always seeking word of changes and additions to the information given here. Appendix A provides descriptions of those standards for which no Ada binding products or resources were identified. Appendix B contains information on the following repositories and software libraries: the AdaIC's Internet host, Asset Source for Software Engineering Technology (SAIC/ASSET), Defense Software Repository System (DSRS), Electronic Library Services and Applications (ELSA), Public Ada Library (PAL) and the Reuse Information Clearinghouse's (ReuseIC) Internet host. 1.4 Definitions In order to make the treatment more uniform in the various sections, we have asked editors to make careful distinctions among various terms that are often confused or misused. First, we need to be careful in making the distinction between a specification and a product that implements the specification. Specification: Document describing a set of services that can be provided to another user or program. In this context, the specifications are usually provided by some group that is chartered for the purpose of developing and documenting the specification. Sometimes the specification is defined in terms of a specific programming language. In recent years, though, there has been a trend toward defining specifications in a manner that is independent of any particular language. In these cases, one must also define bindings to the various programming languages that are expected to use the services described by the specification. Product: Piece of software that implements a specification. In our case, products are typically provided by vendors who sell them commercially. Occasionally, they exist in the public domain. The next important distinction describes the type of interface provided by the product to permit application programs to access the services described by the specification. Broadly speaking, there are two types of interfaces: implementations and bindings. Implementation: Describes the form of interface where the product or a substantial portion of the product is implemented in the same language as the application program. This permits the application program to use the interface by compiling those portions of the product along with the application program. This form of interface is often found in layered reference models where the layers that are closest to the application program interface are written in the same language as the application. Binding: Describes the form of interface where the product is implemented in a different programming language than the application but exports an interface suitable for the desired programming language. In the case of Ada, we often find that the product is implemented in C but exports a set of procedures that may be called by an Ada program. Unfortunately, the term binding is also used in a more general sense to subsume both of the cases described above. Furthermore, the word binding is often used to describe both the specifications for the interface and the product that implements the interface. Binding specifications can be characterized in various ways: as thick or thin; and as direct or abstract. Thick/Thin: Bindings are sometimes described as "thick" or "thin". (These terms should not be confused with "direct" and "abstract" - see below.) Thickness and thinness refer to the method of specifying the semantics in the specifications document. A thick binding combines descriptions of both the syntax and the semantics provided by the binding. When referring to a thick binding, a user would probably refer only to the binding specification and not have to look at the language-independent functional specification. A thin binding specifies only the syntax of how a particular programming language can access a particular service. The reader of a thin binding would have to look at another document, the language-independent functional specification, to determine the semantics associated with the various syntactical constructions. Direct/Abstract: Concept is often confused with thick/thin. If a language binding generally provides direct access to the functionality of the specification via procedure calls and parameters, then the binding may be called "direct". If, on the other hand, the binding repackages the functionality to exploit the particular characteristics of the language, it may be called "abstract". Access to POSIX pthreads is an interesting and current example. If the standards-writers provide direct Ada procedure calls to create, synchronize and destroy POSIX pthreads, then this will be a direct binding. If, on the other hand, POSIX pthreads are equated to Ada tasks and the pthreads are implicitly manipulated via the language-defined tasking functions, then the binding will be abstract. Finally, we must be very careful to use the word standard appropriately. Standard: The term standard is used only to describe specifications that have completed the formal standardization process by an organization that has the legal authority to create standards. Specifications that have broad industry acceptance, but lack a formal standard may be termed "de facto standards". Specifications that are in a draft stage and have not yet completed the standardization process may be called "draft standards" or "proposed standards." Previous Section Table of Contents Next Section Keyword Search
1.3 Report organization This report is divided into five major sections, including this introductory section of the standards and bindings treated in this article. The second section briefly describes software and other softcopy information available from software libraries. The third section list various Ada bindings on the AdaIC's Internet host and other repositories. The fourth section is a listing of vendor products. The guest editor is responsible only for the contents of the first section. Information in the second section is provided by the software libraries; information in the third section information in the fourth section is provided by vendors. Section 2 describes the history and status of the various standards and bindings. The individual subsections were written by guest authors. If more than one standard exists, it explains the relationships and differences among them and provides background information to aid a reader in making intelligent selections. In particular, if there are competing standards, the section should assist a reader in selecting one for a particular job. This section may include notes on the availability of conforming products as well as commenting on detailed documentation describing the standards. When appropriate, historical work is briefly described. Section 3 provides the reader with information on other standards and specifications for which Ada bindings are available. This list was generated after searching repositories and vendor product lists. Many of these standards and specifications are located on the AdaIC Internet host. Section 4 provides information on the various Ada bindings available on the AdaIC's Internet host and other repositories. The majority of the bindings in this section can be downloaded at no charge from the AdaIC host (sw-eng.falls-church.va.us). Section 5 provides information about commercially available bindings products. Information in this section was provided by vendors and collated by the AdaIC. It has not been verified, and neither the editors nor any of the collaborators should be held liable for its correctness or completeness. Further, it should be noted that with continuing developments, it is almost certain that some information has been superseded, and more products and services are available than are listed here. The AdaIC is always seeking word of changes and additions to the information given here. Appendix A provides descriptions of those standards for which no Ada binding products or resources were identified. Appendix B contains information on the following repositories and software libraries: the AdaIC's Internet host, Asset Source for Software Engineering Technology (SAIC/ASSET), Defense Software Repository System (DSRS), Electronic Library Services and Applications (ELSA), Public Ada Library (PAL) and the Reuse Information Clearinghouse's (ReuseIC) Internet host. 1.4 Definitions In order to make the treatment more uniform in the various sections, we have asked editors to make careful distinctions among various terms that are often confused or misused. First, we need to be careful in making the distinction between a specification and a product that implements the specification. Specification: Document describing a set of services that can be provided to another user or program. In this context, the specifications are usually provided by some group that is chartered for the purpose of developing and documenting the specification. Sometimes the specification is defined in terms of a specific programming language. In recent years, though, there has been a trend toward defining specifications in a manner that is independent of any particular language. In these cases, one must also define bindings to the various programming languages that are expected to use the services described by the specification. Product: Piece of software that implements a specification. In our case, products are typically provided by vendors who sell them commercially. Occasionally, they exist in the public domain. The next important distinction describes the type of interface provided by the product to permit application programs to access the services described by the specification. Broadly speaking, there are two types of interfaces: implementations and bindings. Implementation: Describes the form of interface where the product or a substantial portion of the product is implemented in the same language as the application program. This permits the application program to use the interface by compiling those portions of the product along with the application program. This form of interface is often found in layered reference models where the layers that are closest to the application program interface are written in the same language as the application. Binding: Describes the form of interface where the product is implemented in a different programming language than the application but exports an interface suitable for the desired programming language. In the case of Ada, we often find that the product is implemented in C but exports a set of procedures that may be called by an Ada program. Unfortunately, the term binding is also used in a more general sense to subsume both of the cases described above. Furthermore, the word binding is often used to describe both the specifications for the interface and the product that implements the interface. Binding specifications can be characterized in various ways: as thick or thin; and as direct or abstract. Thick/Thin: Bindings are sometimes described as "thick" or "thin". (These terms should not be confused with "direct" and "abstract" - see below.) Thickness and thinness refer to the method of specifying the semantics in the specifications document. A thick binding combines descriptions of both the syntax and the semantics provided by the binding. When referring to a thick binding, a user would probably refer only to the binding specification and not have to look at the language-independent functional specification. A thin binding specifies only the syntax of how a particular programming language can access a particular service. The reader of a thin binding would have to look at another document, the language-independent functional specification, to determine the semantics associated with the various syntactical constructions. Direct/Abstract: Concept is often confused with thick/thin. If a language binding generally provides direct access to the functionality of the specification via procedure calls and parameters, then the binding may be called "direct". If, on the other hand, the binding repackages the functionality to exploit the particular characteristics of the language, it may be called "abstract". Access to POSIX pthreads is an interesting and current example. If the standards-writers provide direct Ada procedure calls to create, synchronize and destroy POSIX pthreads, then this will be a direct binding. If, on the other hand, POSIX pthreads are equated to Ada tasks and the pthreads are implicitly manipulated via the language-defined tasking functions, then the binding will be abstract. Finally, we must be very careful to use the word standard appropriately. Standard: The term standard is used only to describe specifications that have completed the formal standardization process by an organization that has the legal authority to create standards. Specifications that have broad industry acceptance, but lack a formal standard may be termed "de facto standards". Specifications that are in a draft stage and have not yet completed the standardization process may be called "draft standards" or "proposed standards." Previous Section Table of Contents Next Section Keyword Search
Section 2 describes the history and status of the various standards and bindings. The individual subsections were written by guest authors. If more than one standard exists, it explains the relationships and differences among them and provides background information to aid a reader in making intelligent selections. In particular, if there are competing standards, the section should assist a reader in selecting one for a particular job. This section may include notes on the availability of conforming products as well as commenting on detailed documentation describing the standards. When appropriate, historical work is briefly described.
Section 3 provides the reader with information on other standards and specifications for which Ada bindings are available. This list was generated after searching repositories and vendor product lists. Many of these standards and specifications are located on the AdaIC Internet host.
Section 4 provides information on the various Ada bindings available on the AdaIC's Internet host and other repositories. The majority of the bindings in this section can be downloaded at no charge from the AdaIC host (sw-eng.falls-church.va.us).
Section 5 provides information about commercially available bindings products. Information in this section was provided by vendors and collated by the AdaIC. It has not been verified, and neither the editors nor any of the collaborators should be held liable for its correctness or completeness. Further, it should be noted that with continuing developments, it is almost certain that some information has been superseded, and more products and services are available than are listed here. The AdaIC is always seeking word of changes and additions to the information given here.
Appendix A provides descriptions of those standards for which no Ada binding products or resources were identified.
Appendix B contains information on the following repositories and software libraries: the AdaIC's Internet host, Asset Source for Software Engineering Technology (SAIC/ASSET), Defense Software Repository System (DSRS), Electronic Library Services and Applications (ELSA), Public Ada Library (PAL) and the Reuse Information Clearinghouse's (ReuseIC) Internet host.
1.4 Definitions In order to make the treatment more uniform in the various sections, we have asked editors to make careful distinctions among various terms that are often confused or misused. First, we need to be careful in making the distinction between a specification and a product that implements the specification. Specification: Document describing a set of services that can be provided to another user or program. In this context, the specifications are usually provided by some group that is chartered for the purpose of developing and documenting the specification. Sometimes the specification is defined in terms of a specific programming language. In recent years, though, there has been a trend toward defining specifications in a manner that is independent of any particular language. In these cases, one must also define bindings to the various programming languages that are expected to use the services described by the specification. Product: Piece of software that implements a specification. In our case, products are typically provided by vendors who sell them commercially. Occasionally, they exist in the public domain. The next important distinction describes the type of interface provided by the product to permit application programs to access the services described by the specification. Broadly speaking, there are two types of interfaces: implementations and bindings. Implementation: Describes the form of interface where the product or a substantial portion of the product is implemented in the same language as the application program. This permits the application program to use the interface by compiling those portions of the product along with the application program. This form of interface is often found in layered reference models where the layers that are closest to the application program interface are written in the same language as the application. Binding: Describes the form of interface where the product is implemented in a different programming language than the application but exports an interface suitable for the desired programming language. In the case of Ada, we often find that the product is implemented in C but exports a set of procedures that may be called by an Ada program. Unfortunately, the term binding is also used in a more general sense to subsume both of the cases described above. Furthermore, the word binding is often used to describe both the specifications for the interface and the product that implements the interface. Binding specifications can be characterized in various ways: as thick or thin; and as direct or abstract. Thick/Thin: Bindings are sometimes described as "thick" or "thin". (These terms should not be confused with "direct" and "abstract" - see below.) Thickness and thinness refer to the method of specifying the semantics in the specifications document. A thick binding combines descriptions of both the syntax and the semantics provided by the binding. When referring to a thick binding, a user would probably refer only to the binding specification and not have to look at the language-independent functional specification. A thin binding specifies only the syntax of how a particular programming language can access a particular service. The reader of a thin binding would have to look at another document, the language-independent functional specification, to determine the semantics associated with the various syntactical constructions. Direct/Abstract: Concept is often confused with thick/thin. If a language binding generally provides direct access to the functionality of the specification via procedure calls and parameters, then the binding may be called "direct". If, on the other hand, the binding repackages the functionality to exploit the particular characteristics of the language, it may be called "abstract". Access to POSIX pthreads is an interesting and current example. If the standards-writers provide direct Ada procedure calls to create, synchronize and destroy POSIX pthreads, then this will be a direct binding. If, on the other hand, POSIX pthreads are equated to Ada tasks and the pthreads are implicitly manipulated via the language-defined tasking functions, then the binding will be abstract. Finally, we must be very careful to use the word standard appropriately. Standard: The term standard is used only to describe specifications that have completed the formal standardization process by an organization that has the legal authority to create standards. Specifications that have broad industry acceptance, but lack a formal standard may be termed "de facto standards". Specifications that are in a draft stage and have not yet completed the standardization process may be called "draft standards" or "proposed standards." Previous Section Table of Contents Next Section Keyword Search
First, we need to be careful in making the distinction between a specification and a product that implements the specification.
In this context, the specifications are usually provided by some group that is chartered for the purpose of developing and documenting the specification. Sometimes the specification is defined in terms of a specific programming language. In recent years, though, there has been a trend toward defining specifications in a manner that is independent of any particular language. In these cases, one must also define bindings to the various programming languages that are expected to use the services described by the specification.
In our case, products are typically provided by vendors who sell them commercially. Occasionally, they exist in the public domain.
The next important distinction describes the type of interface provided by the product to permit application programs to access the services described by the specification. Broadly speaking, there are two types of interfaces: implementations and bindings.
This permits the application program to use the interface by compiling those portions of the product along with the application program. This form of interface is often found in layered reference models where the layers that are closest to the application program interface are written in the same language as the application.
In the case of Ada, we often find that the product is implemented in C but exports a set of procedures that may be called by an Ada program.
Unfortunately, the term binding is also used in a more general sense to subsume both of the cases described above. Furthermore, the word binding is often used to describe both the specifications for the interface and the product that implements the interface. Binding specifications can be characterized in various ways: as thick or thin; and as direct or abstract.
When referring to a thick binding, a user would probably refer only to the binding specification and not have to look at the language-independent functional specification. A thin binding specifies only the syntax of how a particular programming language can access a particular service. The reader of a thin binding would have to look at another document, the language-independent functional specification, to determine the semantics associated with the various syntactical constructions.
Access to POSIX pthreads is an interesting and current example. If the standards-writers provide direct Ada procedure calls to create, synchronize and destroy POSIX pthreads, then this will be a direct binding. If, on the other hand, POSIX pthreads are equated to Ada tasks and the pthreads are implicitly manipulated via the language-defined tasking functions, then the binding will be abstract.
Finally, we must be very careful to use the word standard appropriately.
Previous Section Table of Contents Next Section Keyword Search