This category contains a wide variety of different programming languages that are used around the world. C++, C, BASIC and Ruby are some of the languages who have standards contained in this section.
This document specifies requirements for implementations of the C++ programming language. The first such requirement is that they implement the language, so this document also defines C++. Other requirements and relaxations of the first requirement appear at various places within this document. C++ is a general purpose programming language based on the C programming language as described in ISO/IEC 9899:2018 Programming languages C (hereinafter referred to as the C standard ). C++ provides many facilities beyond those provided by C, including additional data types, classes, templates, exceptions, namespaces, operator overloading, function name overloading, references, free store management operators, and additional library facilities.
1 This document specifies the form and establishes the interpretation of programs written in the C
programming language.1) It specifies
- the representation of C programs;
- the syntax and constraints of the C language;
- the semantic rules for interpreting C programs;
- the representation of input data to be processed by C programs;
- the representation of output data produced by C programs;
- the restrictions and limits imposed by a conforming implementation of C.
2 This document does not specify
- the mechanism by which C programs are transformed for use by a data-processing system;
- the mechanism by which C programs are invoked for use by a data-processing system;
- the mechanism by which input data are transformed for use by a C program;
- the mechanism by which output data are transformed after being produced by a C program;
- the size or complexity of a program and its data that will exceed the capacity of any specific
data-processing system or the capacity of a particular processor;
- all minimal requirements of a data-processing system that is capable of supporting a conforming
implementation.
This specification describes the form and establishes the interpretation of programs written in the C# programming language. It describes:
— The representation of C# programs;
— The syntax and constraints of the C# language;
— The semantic rules for interpreting C# programs;
— The restrictions and limits imposed by a conforming implementation of C#.
This specification does not describe
— The mechanism by which C# programs are transformed for use by a data-processing system;
— The mechanism by which C# applications are invoked for use by a data-processing system;
— The mechanism by which input data are transformed for use by a C# application;
— The mechanism by which output data are transformed after being produced by a C# application;
— The size or complexity of a program and its data that will exceed the capacity of any specific data-processing system or the capacity of a particular processor;
— All minimal requirements of a data-processing system that is capable of supporting a conforming implementation.
This standard is designed to promote the interchangeability of DIBOL programs among a variety of computers. Programs conforming to this standard will be said to be written in DIBOL.
Specifies an interface between a Forth System and a Forth Program by defining the words provided by a Standard System.
Specifies the programming language which is derived from the ANSI X3.113-1987. For details of the syntax and semantics see ANSI X3.113-1987. Annexes A and B are for information only.
Promotes the interchangeability of BASIC programs among a variety of automatic data processing systems.
1. This document specifies the form and establishes the interpretation of programs expressed in the base Fortran language. The purpose of this document is to promote portability, reliability, maintainability, and efficient execution of Fortran programs for use on a variety of computing systems.
2. This document specifies
— the forms that a program written in the Fortran language can take,
— the rules for interpreting the meaning of a program and its data,
— the form of the input data to be processed by such a program, and
— the form of the output data resulting from the use of such a program.
3. Except where stated otherwise, requirements and prohibitions specified by this document apply to programs
rather than processors.
4. This document does not specify
— the mechanism by which programs are transformed for use on computing systems,
— the operations required for setup and control of the use of programs on computing systems,
— the method of transcription of programs or their input or output data to or from a storage medium,
— the program and processor behavior when this document fails to establish an interpretation except for the processor detection and reporting requirements in items (2) to (10) of 4.2,
— the maximum number of images, or the size or complexity of a program and its data that will exceed the capacity of any particular computing system or the capability of a particular processor,
— the mechanism for determining the number of images of a program,
— the physical properties of an image or the relationship between images and the computational elements of a computing system,
— the physical properties of the representation of quantities and the method of rounding, approximating, or computing numeric values on a particular processor, except by reference to ISO/IEC/IEEE 60559:2011 under conditions specified in Clause 17,
— the physical properties of input/output records, files, and units, or
— the physical properties and implementation of storage.
This part of ISO/IEC 1539 defines facilities in Fortran for the manipulation of character strings of dynamically variable length. This part of ISO/IEC 1539 provides an auxiliary standard for the version of the Fortran language specified by ISO/IEC 1539-1: 1997 and informally known as Fortran 95.
A program that conforms with 1539-2: 1994 also conforms with this standard.
This part of ISO/IEC 1539 is an auxiliary standard to that defining Fortran 95 in that it defines additional facilities to those defined intrinsically in the primary language standard. A processor conforming to the Fortran 95 standard is not required also to conform to this part of ISO/IEC 1539. However, conformance to this part of ISO/IEC 1539 assumes conformance to the primary Fortran 95 standard.
This part of ISO/IEC 1539 prescribes the name of a Fortran module, the name of a derived data type to be used to represent varying-length strings, the interfaces for the procedures and operators to be provided to manipulate objects of this type, and the semantics that are required for each of the entities made accessible by this module.
This part of ISO/IEC 1539 does not prescribe the details of any implementation. Neither the method used to represent the data entities of the defined type nor the algorithms used to implement the procedures or operators whose interfaces are defined by this part of ISO/IEC 1539 are prescribed. A conformant implementation may use any representation and any algorithms, subject only to the requirement that the publicly accessible names and interfaces conform to this part of ISO/IEC 1539, and that the semantics are as required by this part of ISO/IEC 1539 and those of ISO/IEC 1539-1 : 1997.
It should be noted that a processor is not required to implement this part of ISO/IEC 1539 in order to be a standard conforming Fortran processor, but if a processor implements facilities for manipulating varying length character strings, it is recommended that this be done in a manner that is conformant with this part of ISO/IEC 1539.
A processor conforming to this part of ISO/IEC 1539 may extend the facilities provided for the manipulation of varying length character strings as long as such extensions do not conflict with this part of ISO/IEC 1539 or with ISO/IEC 1539-1 : 1997.
A module, written in standard conforming Fortran, is referenced in Annex A. This module illustrates one way in which the facilities described in this part of ISO/IEC 1539 could be provided. This module is both conformant with the requirements of this part of ISO/IEC 1539 and, because it is written in standard conforming Fortran, it provides a portable implementation of the required facilities. This module is referenced for information only and is not intended to constrain implementations in any way. This module is a demonstration that at least one implementation, in standard conforming and hence portable Fortran, is possible.
It should be noted that this part of ISO/IEC 1539 defines facilities for dynamically varying length strings of characters of default kind only. Throughout this part of ISO/IEC 1539 all references to intrinsic type CHARACTER should be read as meaning characters of default kind. Similar facilities could be defined for non-default kind characters by a separate, if similar, module for each such character kind.
This part of ISO/IEC 1539 has been designed, as far as is reasonable, to provide for varying length character strings the facilities that are available for intrinsic fixed length character strings. All the intrinsic operations and functions that apply to fixed length character strings have extended meanings defined by this part of ISO/IEC 1539 for varying length character strings. Also a small number of additional facilities are defined that are appropriate because of the essential differences between the intrinsic type and the varying length derived data type.
This International Standard describes the M programming language.
This International Standard specifies an interface between a Forth System and a Forth Program by defining the words provided by a Standard System.
This International Standard specifies:
This International Standard does not specify:
ISO/IEC 8652:2012 specifies the form and meaning of programs written in the programming language Ada. Its purpose is to promote the portability of Ada programs to a variety of computing systems.
This third edition of ISO/IEC 8652 focuses on improvements in those user domains where safety and criticality are prime concerns. It enhances the functionality of containers, improves the ability to write and enforce contracts for Ada entities (for instance, via preconditions), and adds to the capabilities of Ada to perform on multicore and multithreaded architectures.
Ada is designed to support the construction of long‐lived, highly reliable software systems. The language includes facilities to define packages of related types, objects, and operations. The packages may be parameterized and the types may be extended to support the construction of libraries of reusable, adaptable software components. The operations may be implemented as subprograms using conventional sequential control structures, or as entries that include synchronization of concurrent threads of control as part of their invocation. Ada supports object‐oriented programming by providing classes and interfaces, inheritance, polymorphism of variables and methods, and generic units. The language treats modularity in the physical sense as well, with a facility to support separate compilation.
The language provides rich support for real‐time, concurrent programming, and includes facilities for multicore and multiprocessor programming. Errors can be signaled as exceptions and handled explicitly. The language also covers systems programming; this requires precise control over the representation of data and access to system‐dependent properties. Finally, a predefined environment of standard packages is provided, including facilities for, among others, input‐output, string manipulation, numeric elementary functions, random number generation, and definition and use of containers.
Foremost in the design of Ada is the intent to increase the reliability of programs by compiletime checking and rejection of unsafe programs.
The Ada Semantic Interface Specification (ASIS) is an interface between an Ada environment (as defined by ISO/IEC 8652:1995) and any tool requiring information from this environment. An Ada environment includes valuable semantic and syntactic information. ASIS is an open and published callable interface which gives CASE tool and application developers access to this information. ASIS has been designed to be independent of underlying Ada environment implementations, thus supporting portability of software engineering tools while relieving tool developers from needing to understand the complexities of an Ada environment's proprietary internal representation.
Examples of tools that benefit from the ASIS interface include: automated code monitors, browsers, call tree tools, code reformators, coding standards compliance tools, correctness verifiers, debuggers, dependency tree analysis tools, design tools, document generators, metrics tools, quality assessment tools, reverse engineering tools, re-engineering tools, safety and security tools, style checkers, test tools, timing estimators, and translators.
This International Standard specifies the form and meaning of the ASIS interface to the Ada compilation environment.
This International Standard is applicable to tools and applications needing syntactic and semantic information in the Ada compilation environment.
Extent
This International Standard specifies:
This International Standard does not specify:
Structure
This International Standard contains twenty-three clauses and four annexes.
Clause 1 is general in nature providing the scope of this International Standard, normative references, and definitions.
Clause 2 identifies the ASIS technical concepts. Here the Ada compilation environment to which ASIS interfaces is described. The concept of queries is presented. The ASIS package architecture is presented.
The packages that comprise the ASIS International Standard are provided in Clauses 3 through 23. These packages are provided in the correct compilation order and when presented in electronic format are compilable.
The following annexes are informative:
The major package interfaces visible to ASIS users are identified as clauses facilitating access from the table of contents.
The ASIS interface is compilable. Consequently, Sentinels have been used to mark portions of the ASIS text with comments appropriate to an ASIS implementor and an ASIS user.
The sentinels and their meanings are:
Conformity with this International Standard
Implementation conformance requirements
An ASIS implementation includes all the hardware and software that implements the ASIS specification for a given Ada implementation and that provides the functionality required by the ASIS specification. An ASIS implementor is a company, institution, or other group (such as a vendor) who develops an ASIS implementation. A conforming ASIS implementation shall meet all of the following criteria:
Implementation conformance documentation
A conformance document shall be available for an implementation claiming conformance to this International Standard. The conformance document shall have the same structure as this International Standard, with the information presented in the equivalently numbered clauses, and subclauses. The conformance document shall not contain information about extended facilities or capabilities outside the scope of this International Standard.
The conformance document shall contain a statement that indicates the full name, number, and date of the International Standard that applies. The conformance document may also list software standards approved by ISO/IEC or any ISO/IEC member body that are available for use by a Basic or Fully Conforming ASIS Application. Applicable characteristics whose documentation is required by one of these standards, or by standards of government bodies, may also be included.
The conformance document shall describe the behavior of the implementation for all implementation-defined features defined in this International Standard. This requirement shall be met by listing these features and providing either a specific reference to the system documentation or providing full syntax and semantics of these features. The conformance document shall specify the behavior of the implementation for those features where this International Standard states that implementations may vary.
No specifications other than those described in this subclause shall be present in the conformance document.
The phrase “shall be documented” in this International Standard means that documentation of the feature shall appear in the conformance document, as described previously, unless the system documentation is explicitly mentioned.
The system documentation should also contain the information found in the conformance document.
Implementation conformance categories
An implementation is required to define all of the subprograms for all of the operations defined in this International Standard, including those whose implementation is optional. Required functionality is the subset of ASIS facilities which are not explicitly identified in the ASIS standard as optional. Optional functionality is the subset of ASIS facilities which are explicitly identified in the ASIS standard as optional which may legitimately be omitted from a Basic Conforming ASIS implementation. Optional interfaces shall be included in any Fully Conforming ASIS implementation, unless stated otherwise in the ASIS specification. An application that accesses an Ada environment's semantic tree (e.g., Diana Tree) directly using work-arounds is not considered to be a conformant application. All Conforming Applications fall within one of the categories defined below.
If an unimplemented feature is used, the exception Asis.ASIS_Failed shall be raised and Asis.Implementation_Status shall return the value for Error_Kinds of Not_Implemented_Error.
There are four categories of conforming ASIS implementations:
Basic conforming ASIS implementation
A Basic Conforming ASIS Implementation is an ASIS implementation supporting all required interfaces defined within this International Standard.
Fully conforming ASIS implementation
A Fully Conforming ASIS Implementation is an ASIS implementation supporting all required and all optional interfaces defined within this International Standard.
Basic conforming ASIS implementation using extensions
A Basic Conforming ASIS Implementation Using Extensions is an ASIS implementation that differs from a Basic Conforming ASIS Implementation only in that it uses nonstandard extensions that are consistent with this International Standard. Such an implementation shall fully document its extended facilities, in addition to the documentation required for a Basic Conforming ASIS Implementation.
Fully conforming ASIS implementation using extensions
A Fully Conforming ASIS Implementation Using Extensions is an ASIS implementation that differs from a Fully Conforming ASIS Implementation only in that it uses nonstandard extensions that are consistent with this International Standard. Such an implementation shall fully document its extended facilities, in addition to the documentation required for a Fully Conforming ASIS Implementation.
Application conformance categories
An ASIS application is any programming system or any set of software components making use of ASIS queries to obtain information about any set of Ada components. All ASIS applications claiming conformance to this International Standard shall use a Conforming ASIS Implementation with or without extensions.
Basic conforming ASIS application
A Basic Conforming ASIS Application is an application that only uses the required facilities defined within this International Standard. It shall be portable to any Conforming ASIS Implementation.
Fully conforming ASIS application
A Fully Conforming ASIS Application is an application that only uses the required facilities and the optional facilities defined within this International Standard. It shall be portable to any Fully Conforming ASIS Implementation.
Basic conforming ASIS application using extensions
A Basic Conforming ASIS Application Using Extensions is an application that differs from a Basic Conforming ASIS Application only in that it uses nonstandard, implementation provided, extended facilities that are consistent with this International Standard. Such an application should fully document its requirements for these extended facilities. A Basic Conforming ASIS Application Using Extensions may or may not be portable to other Basic or Fully Conforming ASIS Implementation Using Extensions.
Fully conforming ASIS application using extensions
A Fully Conforming ASIS Application Using Extensions is an application that differs from a Fully Conforming ASIS Application only in that it uses nonstandard, implementation provided, extended facilities that are consistent with this International Standard. Such an application should fully document its requirements for these extended facilities. A Fully Conforming ASIS Application Using Extensions may or may not be portable to other Fully Conforming ASIS Implementation Using Extensions.
Implementation permissions
The ASIS Application Program Interface (API) may be implemented through a variety of approaches. Approaches permitted by this International Standard are based on the traditional approach and the client /server approach. These implementation permissions are depicted in Figure 1 and described below:
Traditional approach (permission 1)
Traditionally, the ASIS API implementation is intended to execute on the node containing the implementor's Ada software engineering environment and the desired Ada compilation environment. Because the ASIS API interfaces directly, ASIS performs at its best. It is expected that most ASIS implementors will support this approach as it requires little additional effort when alternative approaches are supported. In Figure 1, the client tool using Permission 1 uses the ASIS specification exactly as specified in this International Standard. ASIS tools and applications are compiled in the implementor's environment.
Client / server approach (permission 2)
As an alternative, a client / server approach can be used to implement the ASIS API. Here the ASIS API is supported by a server; ASIS client tools can request ASIS services within the supported network.
Figure 1 identifies four ASIS client tools using permission 2 capable of interfacing with an ASIS Object Request Broker (ORB) server. One client tool is written in Ada, one in Java, one in C++, and one in Smalltalk. The ORB serves as a broker between the client and server on a network consisting of many nodes. Server location and services are registered with the ORB. A client needing the services interfaces with the ORB, who brokers the needed server interface information. The interface between a client and server is written as an interface specification in the Interface Definition Language (IDL). IDL is very different from most computer languages; when IDL is compiled, the interface specification is produced in either Ada, Java, C++, or Smalltalk. In addition, the necessary artifacts are produced to register the client or server interface with the ORB.
Distributed traditional approach (permission 3)
The Ada specification created by the compilation of this ASIS API in IDL is semantically equivalent to this ASIS standard, but not syntactically identical. An ASIS Client tool written in Ada interfaces to the ASIS API as specified in this International Standard. As shown in Figure 1, the ASIS API encapsulates the ASIS ORB client as generated from the compilation of the ASIS IDL into Ada. Client tools using either permission 1 or permission 3 are, most likely, identical. Client tools developed using permission 3 can be developed as plug and play.
ASIS dynamic client approach (permission 4)
In addition to using traditional compiled tools through the client / server interface, ORBs can provide a Dynamic Interface Invocation (DII) capability where rather general purpose tools can access the interface dynamically. Shown in Figure 1, such a tool behaves more like a browser. It accesses the ASIS IDL as registered with the server and browses through the services provided by the ASIS interface. Use of this capability with ASIS is extremely cumbersome and manually intensive. However, this provides a user access to information across the interface that had not been preprogrammed by a tool.
Classification of errors
ASIS reports all operational errors by raising an exception. Whenever an ASIS implementation raises one of the exceptions declared in package Asis.Exceptions, it will previously have set the values returned by the Status and Diagnosis queries to indicate the cause of the error. The possible values for Status are indicated here along with suggestions for the associated contents of the Diagnosis string.
ASIS applications are encouraged to follow this same convention whenever they explicitly raise any ASIS exception to always record a Status and Diagnosis prior to raising the exception. Values of errors along with their general meanings are:
| Not_An_Error | -- No error is presently recorded |
| Value_Error | -- Routine argument value invalid |
| Initialization_Error | -- ASIS is uninitialized |
| Environment_Error | -- ASIS could not initialize |
| Parameter_Error | -- Bad Parameter given to Initialize |
| Capacity_Error | -- Implementation overloaded |
| Name_Error | -- Context/unit not found |
| Use_Error | -- Context/unit not use/open-able |
| Data_Error | -- Context/unit bad/invalid/corrupt |
| Text_Error | -- The program text cannot be located |
| Storage_Error | -- Storage_Error suppressed |
| Obsolete_Reference_Error | -- Semantic reference is obsolete |
| Unhandled_Exception_Error | -- Unexpected exception suppressed |
| Not_Implemented_Error | -- Functionality not implemented |
| Internal_Error | -- Implementation internal failure |
Diagnostic messages may be more specific.
A set of exceptions shall be raised for the following circumstances:
The M Windowing API (MWAPI) extends the M programming technology with the addition of capabilities for developing and operating graphical user interface (GUI) applications.
For the purposes of this International Standard, an application is defined as a collection of one or more M routines using MWAPI capabilities and a user is a person utilizing such an application.
ISO/IEC 23271:2012 defines the Common Language Infrastructure (CLI) in which applications written in multiple high-level languages can be executed in different system environments without the need to rewrite those applications to take into consideration the unique characteristics of those environments. It consists of six partitions.
ISO/IEC 30170:2012 specifies the syntax and semantics of the computer programming language Ruby, and the requirements for conforming Ruby processors, strictly conforming Ruby programs, and conforming Ruby programs.
It does not specify
This International Standard specifies the semantics and syntax of the computer programming language Pascal by specifying requirements for a processor and for a conforming program. Two levels of compliance are defined for both processors and programs.
This International Standard does not specify
Specifies the syntax and semantics of the programming language by specifying requirements for a processor and for a conforming program. Includes an alphabetical index. Annexes A to G are for information only.
Describes the semantics and syntax of the APL progamming language and the environment for the application, interchange and the portability of APL programs. Defines requirements for conformance with the standard.
ISO/IEC 9496:2003 defines the ITU-T programming language CHILL. CHILL is a strongly typed, block structured and object-oriented language designed primarily for the implementation of large and complex embedded systems.
CHILL was designed to provide reliability and run time efficiency, at the same time sufficient flexibility and powerfulness to encompass the required range of applications. CHILL also provides facilities that encourage piecewise and modular development of large systems.
Establishes the form for, and the interpretation of ,programs expressed in the Automatically Programmed Tools (APT) language and of the System-Neutral CLFILE (SCL), which can be generated by processors, such as APT, or by graphical systems. The purpose is to promote portability of these input language programs to a wide variety of computers. In addition, the SCL permits commonality and portability, regardless of the source that produces it, to a wide variety of manufacturing equipment. APT is an English-like language for describing operations for numerically controlled machines. An APT language input program is converted by a computer processor and, probably, subsequently by a postprocessor into an ordered set of instructions for numerically controlled machines.
Adopts ANSI standard X3.53-1976 and French standard NF Z 65-500 as PL/1 programming language standard for the English and French versions, respectively.
The language defined is different from those of previous PL/I standards, although substantially upward compatible, at the source program and semantic level. The differences are summarized in appendix A. Specifies the syntax and semantics of conforming PL/I programs. Defines a conforming processor (or conforming implementation) only in terms of those conforming programs. The definition is accomplished by specifying a conceptual PL/I machine which translates and interprets intended PL/I programs.
Promotes the portability of Common Lisp programs among a variety of data processing systems. It is a language specification aimed at an audience of implementors and knowledgeable programmers. It is neither a tutorial nor an implementation guide.
Specifies the form and establishes the interpretation of programs written in the PL/B programming language. The standard is designed to promote portability of PL/B programs among a variety of data processing systems. It is intended for use by implementors
Provides errata, issued in response to questions that have been raised regarding certain specifications contained in the content of: X3.274-1996, Programming Language Rexx.
This is a standard for the Smalltalk langauge such that: 1. working only from the standard, a conforming implementation can be produced, 2. Smalltalk programs which conform to the standard will have the same execution semantics on any conforming implementation, and 3. the standard shall be sufficiently complete to allow useful Smalltalk programs to be constructed.