From 14025d22ce3d66c9d235e57221ec4653e00f972c Mon Sep 17 00:00:00 2001 From: Jedidiah Barber Date: Fri, 26 Nov 2021 20:17:43 +1300 Subject: Switched to .xhtml extension, fixed some minor bugs --- project/templates/steelman.html | 2437 --------------------------------------- 1 file changed, 2437 deletions(-) delete mode 100644 project/templates/steelman.html (limited to 'project/templates/steelman.html') diff --git a/project/templates/steelman.html b/project/templates/steelman.html deleted file mode 100644 index 3ae2d95..0000000 --- a/project/templates/steelman.html +++ /dev/null @@ -1,2437 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}D, Parasail, Pascal and Rust vs The Steelman{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

D, Parasail, Pascal, and Rust vs The Steelman

- -
29/10/2017
- - -
Overview
- -

From 1975 to 1978 the United States Department of Defense sought to establish a set of -requirements for a single high level programming language that would also be appropriate for use in -Defense embedded systems. After successively more refined versions of the requirements from Strawman -through to Ironman, this effort culminated in Steelman. The Ada programming language, possibly the -gold standard language for writing safe and secure software, was designed to comply with Steelman. -

- -

In 1996 David A. Wheeler wrote a paper that compared Ada, C, C++, and Java against the Steelman. This -served to highlight the strengths and weaknesses of those languages, areas that could be improved, -and a scant few requirement points that perhaps aren't even applicable anymore. Since then several -more programming languages capable of systems work have been created, so it's time for an update. -More datapoints! Hence, this article will conduct a similar comparison, instead using D, Parasail, -Pascal, and Rust.

- - -
The Languages
- -

D was created originally as a reworking of C++ -in 2000-2001. It serves to represent a progression of the C language family, adding features -including contracts, optional garbage collection, and a standard threading model.

- -

Parasail is a -research language created in 2009 by AdaCore, the main vendor of Ada compiler tooling today. The -language is designed with implicit parallelism throughout, simplifying and adding static checking to eliminate as many sources of errors -as possible. It represents a possible future direction for Ada derived languages.

- -

Pascal -, like C, predates the Steelman requirements and so they cannot have had any influence at all on -the language. It was designed for formal specification and -teaching -algorithms. Later dialects were used to develop several high profile software projects, -including Skype, Photoshop, and the original Mac OS. It is useful to consider as a precusor of Ada, -sharing many points of functionality and style.

- -

Rust is the newest language here, -created in 2010. It is an odd mix of C and ML influence, placing more emphasis on the functional -paradigm than other systems languages. Its main claim to fame is adding another method of heap -memory safety via affine typing.

- - - - - - - - - - -
-
- Logo for the D programming language -
D
-
- 		-
- Logo for the Parasail programming language -
Parasail
-
-
-
- A picture of Blaise Pascal to stand in as a logo for the Pascal programming language -
Pascal*
-
- 		-
- Logo for the Rust programming language -
Rust
-
-
- -

* Pascal does not have an official logo, so a picture of -Blaise Pascal, in whose -honour the language is named, will have to do.

- - -
Rules for Comparison
- -

The rule used for this article is that a language provides a feature if:

-
    -
  1. that feature is defined in the documents widely regarded as the language's defining - document(s), or
    2. -
  2. that feature is widely implemented by compilers typically used for that language with - essentially the same semantics.
    3. -
- -

Note the bolded difference from the rules in Wheeler's paper. This is so later dialects of Pascal -can be considered, rather than strictly adhering to the ISO standard. The other three languages are -unaffected by this change. Aside from that, effort has been made to keep the evaluation as similar -as practical to the previous work.

- -

The defining documents used for each of these languages are as follows:

- - - -
Results and Conclusions
- -

The appendix lists the Steelman requirements and how well each language supports them. The -following table shows a summary:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Language"No""Partial""Mostly""Yes"Percentage with "Mostly" or "Yes"
D715256681%
Parasail116118585%
Pascal1916116769%
Rust1219235973%
- -

Note that these raw numbers should not be taken at face value. They are a summary of how well the -overall requirements are met, no more, no less. Attention should be directed towards specific -requirements to determine the strengths and weaknesses of each language and the suitability for a -particular purpose. Furthermore, some features are not covered by Steelman at all, such as support -for functional programming or object oriented programming.

- -

The following are high level comments on these programming languages and how they relate:

- - - -
Appendix: Table Comparing the Languages to Steelman
- -

As in Wheeler's paper, this table shows each Steelman requirement on the left and then how well -each of the four languages considered meet that requirement on the right. Some explanatory notes are -included for a few of the requirements.

- -

Note that due to the standardisation issues each of these languages has, a (fortunately quite -low) number of these turned out to be educated guesses. Fairness was the goal, but nonetheless -reader discretion is advised.

- - -
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
RequirementDParasailPascalRust
- 1A. Generality. The language shall provide generality only to the extent necessary - to satisfy the needs of embedded computer applications. Such applications involve - real time control, self diagnostics, input-output to nonstandard peripheral devices, - parallel processing, numeric computation, and file processing. - yesno?yes?yes?
- Parasail does not specify ways to directly control hardware, nor any interfaces to other - languages. -
- 1B. Reliability. The language should aid the design and development of reliable - programs. The language shall be designed to avoid error prone features and to - maximize automatic detection of programming errors. The language shall require some - redundant, but not duplicative, specifications in programs. Translators shall produce - explanatory diagnostic and warning messages, but shall not attempt to correct - programming errors. - yes?yespartial?mostly?
-
- 1C. Maintainability. The language should promote ease of program maintenance. It - should emphasize program readability (i.e., clarity, understandability, and - modifiability of programs). The language should encourage user documentation of - programs. It shall require explicit specification of programmer decisions and shall - provide defaults only for instances where the default is stated in the language - definition, is always meaningful, reflects the most frequent usage in programs, and may - be explicitly overridden. - partial?yes?mostly?partial?
- Parasail was designed with readability in mind, although it suffers slightly from having - several different ways to do something. Pascal was designed for teaching structured - programming. D inherits a lot of the syntactical traps of C-family languages. Rust has - exceedingly terse and difficult to read syntax. -
- 1D. Efficiency. The language design should aid the production of efficient object - programs. Constructs that have unexpectedly expensive implementations should be easily - recognizable by translators and by users. Features should be chosen to have a simple and - efficient implementation in many object machines, to avoid execution costs for available - generality where it is not needed, to maximize the number of safe optimizations - available to translators, and to ensure that unused and constant portions of programs - will not add to execution costs. Execution time support packages of the language shall - not be included in object code unless they are called. - partial?yes?yesyes?
- D incorporates garbage collection to some extent. Parasail is designed to allow as much - implicit parallelism as possible. -
- 1E. Simplicity. The language should not contain unnecessary complexity. It should have a - consistent semantic structure that minimizes the number of underlying concepts. It - should be as small as possible consistent with the needs of the intended applications. - It should have few special cases and should be composed from features that are - individually simple in their semantics. The language should have uniform syntactic - conventions and should not provide several notations for the same concept. No arbitrary - restriction should be imposed on a language feature. - yes?mostlyyesyes
- Parasail allows several syntactical forms that are identical in meaning. -
- 1F. Implementability. The language shall be composed from features that are understood - and can be implemented. The semantics of each feature should be sufficiently well - specified and understandable that it will be possible to predict its interaction with - other features. To the extent that it does not interfere with other requirements, the - language shall facilitate the production of translators that are easy to implement and - are efficient during translation. There shall be no language restrictions that are not - enforceable by translators. - yesyesyesyes
- All of these languages have been reasonably implemented. -
- 1G. Machine Independence. The design of the language should strive for machine - independence. It shall not dictate the characteristics of object machines or operating - systems except to the extent that such characteristics are implied by the semantics of - control structures and built-in operations. It shall attempt to avoid features whose - semantics depend on characteristics of the object machine or of the object machine - operating system. Nevertheless, there shall be a facility for defining those portions of - programs that are dependent on the object machine configuration and for conditionally - compiling programs depending on the actual configuration. - yesyesyesyes
-
- 1H. Complete Definition. The language shall be completely and unambiguously defined. To - the extent that a formal definition assists in achieving the above goals (i.e., all of - section 1), the language shall be formally defined. - yesyesmostly?mostly?
- While Pascal is the only one of these languages with an ISO standard, most Pascal - programming is done with more recent extended dialects. Rust reference material does not - completely describe the language. -
- 2A. Character Set. The full set of character graphics that may be used in source - programs shall be given in the language definition. Every source program shall also have - a representation that uses only the following 55 character subset of the ASCII graphics: - %&'()*+,-./:;<=>? 0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ_ Each additional - graphic (i.e., one in the full set but not in the 55 character set) may be replaced by a - sequence of (one or more) characters from the 55 character set without altering the - semantics of the program. The replacement sequence shall be specified in the language - definition. - mostlymostlymostlymostly
-
- 2B. Grammar. The language should have a simple, uniform, and easily parsed grammar and - lexical structure. The language shall have free form syntax and should use familiar - notations where such use does not conflict with other goals. - partial?yesyespartial?
- Use of familiar notations is something that Parasail arguably takes too far, see 1E. D - inherits some grammar issues from C/C++. Rust has less borrowing from that source but is - still very ad hoc. -
- 2C. Syntactic Extensions. The user shall not be able to modify the source language - syntax. In particular the user shall not be able to introduce new precedence rules or to - define new syntactic forms. - yesyesyesno
- Rust has macros, which can be used to add new syntax to the language. -
- 2D. Other Syntactic Issues. Multiple occurrences of a language defined symbol appearing - in the same context shall not have essentially different meanings. Lexical units (i.e., - identifiers, reserved words, single and multicharacter symbols, numeric and string - literals, and comments) may not cross line boundaries of a source program. All key word - forms that contain declarations or statements shall be bracketed (i.e., shall have a - closing as well as an opening key word). Programs may not contain unmatched brackets of - any kind. - mostlyyesmostlymostly
- D, Pascal, and Rust permit multi line comments. D and Rust use opening and closing - braces rather than key words. -
- 2E. Mnemonic Identifiers. Mnemonically significant identifiers shall be allowed. There - shall be a break character for use within identifiers. The language and its translators - shall not permit identifiers or reserved words to be abbreviated. (Note that this does - not preclude reserved words that are abbreviations of natural language words.) - yesyesyesyes
-
- 2F. Reserved Words. The only reserved words shall be those that introduce special - syntactic forms (such as control structures and declarations) or that are otherwise used - as delimiters. Words that may be replaced by identifiers, shall not be reserved (e.g., - names of functions, types, constants, and variables shall not be reserved). All reserved - words shall be listed in the language definition. - yesyesyesyes
-
- 2G. Numeric Literals. There shall be built-in decimal literals. There shall be no - implicit truncation or rounding of integer and fixed point literals. - mostlyyesmostly?mostly
- Parasail Univ_Integer and Univ_Real types provide arbitrary precision. Rust provides - configurable ways to treat integer overflow, with the default release mode being - wrapping by two's complement. D allows implicit wrapping of integers. Pascal real types - are implementation defined. Only Parasail supports fixed point types. -
- 2H. String Literals. There shall be a built-in facility for fixed length string - literals. String literals shall be interpreted as one-dimensional character arrays. - yesyesyesyes
- Univ_Strings in Parasail are vectors of Univ_Character, not arrays. -
- 2I. Comments. The language shall permit comments that are introduced by a special (one - or two character) symbol and terminated by the next line boundary of the source program. - yesyespartialyes
- Line comments were introduced in Turbo Pascal, but are not part of the ISO standard. -
- 3A. Strong Typing. The language shall be strongly typed. The type of each variable, - array and record component, expression, function, and parameter shall be determinable - during translation. - mostlyyesyesyes
- Some implicit conversion is allowed in D, such as booleans to integral types, one way - conversion from enums to integers, and some automatic promotion of integer types. -
- 3B. Type Conversions. The language shall distinguish the concepts of type (specifying - data elements with common properties, including operations), subtype (i.e., a subset of - the elements of a type, that is characterized by further constraints), and - representations (i.e., implementation characteristics). There shall be no implicit - conversions between types. Explicit conversion operations shall be automatically defined - between types that are characterized by the same logical properties. - partial?yesyes?partial?
- D, Rust do not have subtypes, although class structures in D can be used with contract - programming to provide the same functionality. D allows implicit promotion of integer - types. D, Rust have primitive types that are tightly coupled to the typical - implementation characteristics of computer hardware. -
- 3C. Type Definitions. It shall be possible to define new data types in programs. A type - may be defined as an enumeration, an array or record type, an indirect type, an existing - type, or a subtype of an existing type. It shall be possible to process type definitions - entirely during translation. An identifier may be associated with each type. No - restriction shall be imposed on user defined types unless it is imposed on all types. - mostlyyesyes?mostly
- D, Rust do not have subtypes. D however can emulate similar functionality with type - invariant contracts for user defined classes. -
- 3D. Subtype Constraints. The constraints that characterize subtypes shall include range, - precision, scale, index ranges, and user defined constraints. The value of a subtype - constraint for a variable may be specified when the variable is declared. The language - should encourage such specifications. [Note that such specifications can aid the - clarity, efficiency, maintainability, and provability of programs.] - partialyes?mostly?no
- D does not have subtypes but has similar functionality with class type invariants. Rust - doesn't have subtypes at all. -
- 3-1A. Numeric Values. The language shall provide distinct numeric types for exact and - for approximate computation. Numeric operations and assignment that would cause the most - significant digits of numeric values to be truncated (e.g., when overflow occurs) shall - constitute an exception situation. - partial?yespartial?mostly?
- Numeric overflow does not cause an exception in D, but the language provides standard - ways to check for the situation. Overflow error handling in Pascal is implementation - defined. -
- 3-1B. Numeric Operations. There shall be built-in operations (i.e., functions) for - conversion between the numeric types. There shall be operations for addition, - subtraction, multiplication, division, negation, absolute value, and exponentiation to - integer powers for each numeric type. There shall be built-in equality (i.e., equal and - unequal) and ordering operations (i.e., less than, greater than, less than or equal, and - greater than or equal) between elements of each numeric type. Numeric values shall be - equal if and only if they have exactly the same abstract value. - mostlyyesmostlymostly
- D uses a library abs() function instead of a built-in operator. Pascal does not have - built-in operators for absolute value or exponentiation. Rust uses library abs() and - pow() functions instead of built-in absolute value and exponentiation operators. -
- 3-1C. Numeric Variables. The range of each numeric variable must be specified in - programs and shall be determined by the time of its allocation. Such specifications - shall be interpreted as the minimum range to be implemented and as the maximum range - needed by the application. Explicit conversion operations shall not be required between - numeric ranges. - yesyesyesyes
- Counting built-in integer types as specifying a range, all these languages do so to some - extent. Parasail is the only one that supports user defined custom ranges. -
- 3-1D. Precision. The precision (of the mantissa) of each expression result and variable - in approximate computations must be specified in programs, and shall be determinable - during translation. Precision specifications shall be required for each such variable. - Such specifications shall be interpreted as the minimum accuracy (not significance) to - be implemented. Approximate results shall be implicitly rounded to the implemented - precision. Explicit conversions shall not be required between precisions. - mostlyyesnomostly
- D defines specific precisions for double and float, along with a minimum precision for - real. Custom precisions can be defined for storage only, but all operations happen on - doubles/floats/reals. In Standard Pascal precision of real number types is entirely - implementation defined. Rust defines specific precisions for 32 and 64 bit floats, but - no other control over precision. -
- 3-1E. Approximate Arithmetic Implementation. Approximate arithmetic will be implemented - using the actual precisions, radix, and exponent range available in the object machine. - There shall be built-in operations to access the actual precision, radix, and exponent - range of the implementation. - yesyes?partialyes?
- In Standard Pascal the values taken by real number types are entirely implementation - defined. In practice, this usually means implementation using the actual precisions - available in the object machine. -
- 3-1F. Integer and Fixed Point Numbers. Integer and fixed point numbers shall be treated - as exact numeric values. There shall be no implicit truncation or rounding in integer - and fixed point computations. - mostlyyespartialmostly
- D, Pascal, Rust don't support fixed point numbers, and permit implicit wrapping with - integer calculations. Dealing with overflow, wrapping, and other error conditions in - Pascal is implementation defined. -
- 3-1G. Fixed Point Scale. The scale or step size (i.e., the minimal representable - difference between values) of each fixed point variable must be specified in programs - and be determinable during translation. Scales shall not be restricted to powers of two. - noyesnono
- Of these four languages, only Parasail supports fixed point types. -
- 3-1H. Integer and Fixed Point Operations. There shall be integer and fixed point - operations for modulo and integer division and for conversion between values with - different scales. All built-in and predefined operations for exact arithmetic shall - apply between arbitrary scales. Additional operations between arbitrary scales shall be - definable within programs. - noyesnono
- All support "modulo" operators; D, Pascal, Rust don't support fixed point numbers. -
- 3-2A. Enumeration Type Definitions. There shall be types that are definable in programs - by enumeration of their elements. The elements of an enumeration type may be identifiers - or character literals. Each variable of an enumeration type may be restricted to a - contiguous subsequence of the enumeration. - mostlyyesyesmostly
- D does not permit character literals in an enumeration, nor restriction to a - subsequence. Rust enums are more flexible in content, but still don't support - restriction to a subsequence. -
- 3-2B. Operations on Enumeration Types. Equality, inequality, and the ordering operations - shall be automatically defined between elements of each enumeration type. Sufficient - additional operations shall be automatically defined so that the successor, predecessor, - the position of any element, and the first and last element of the type may be computed. - yesyes?yes?mostly?
-
- 3-2C. Boolean Type. There shall be a predefined type for Boolean values. - yesyesyesyes
- D's boolean type is weakly typed. -
- 3-2D. Character Types. Character sets shall be definable as enumeration types. Character - types may contain both printable and control characters. The ASCII character set shall - be predefined. - yesyesyesyes
-
- 3-3A. Composite Type Definitions. It shall be possible to define types that are - Cartesian products of other types. Composite types shall include arrays (i.e., composite - data with indexable components of homogeneous types) and records (i.e., composite data - with labeled components of heterogeneous type). - yesyesyesyes
- All have arrays and records. -
- 3-3B. Component Specifications. For elements of composite types, the type of each - component (i.e., field) must be explicitly specified in programs and determinable during - translation. Components may be of any type (including array and record types). Range, - precision, and scale specifications shall be required for each component of appropriate - numeric type. - yesyesyesyes
- Range, precision, and scale specifications are included in numeric type definitions - (with support varying, see 3-1). -
- 3-3C. Operations on Composite Types. A value accessing operation shall be automatically - defined for each component of composite data elements. Assignment shall be automatically - defined for components that have alterable values. A constructor operation (i.e., an - operation that constructs an element of a type from its constituent parts) shall be - automatically defined for each composite type. An assignable component may be used - anywhere in a program that a variable of the component's type is permitted. There shall - be no automatically defined equivalence operations between values of elements of a - composite type. - yesyesyesyes
-
- 3-3D. Array Specifications. Arrays that differ in number of dimensions or in component - type shall be of different types. The range of subscript values for each dimension must - be specified in programs and may be determinable at the time of array allocation. The - range of each subscript value must be restricted to a contiguous sequence of integers or - to a contiguous sequence from an enumeration type. - mostlyyesyesmostly
- D and Rust array indexes can only start at zero and cannot use enumerations. -
- 3-3E. Operations on Subarrays. There shall be built-in operations for value access, - assignment, and catenation of contiguous sections of one-dimensional arrays of the same - component type. The results of such access and catenation operations may be used as - actual input parameter. - yesyes?nopartial
- Pascal has extremely limited array slicing and does not have a built-in array - concatenation operator. Rust has array slicing facilities, but lacks a built-in array - concatenation operator. -
- 3-3F. Nonassignable Record Components. It shall be possible to declare constants and - (unary) functions that may be thought of as record components and may be referenced - using the same notation as for accessing record components. Assignment shall not be - permitted to such components. - yesyesno?no?
- D classes can include constants and functions. Parasail type inferfaces can include - constants and functions. -
- 3-3G. Variants. It shall be possible to define types with alternative record structures - (i.e., variants). The structure of each variant shall be determinable during - translation. - yesyes?yesyes
- D classes can be used to simulate runtime variants. D also has untagged unions. Pascal - has variant records. Rust has tagged unions called "sum types". -
- 3-3H. Tag Fields. Each variant must have a nonassignable tag field (i.e., a component - that can be used to discriminate among the variants during execution). It shall not be - possible to alter a tag field without replacing the entire variant. - yesyes?yes?yes
-
- 3-3I. Indirect Types. It shall be possible to define types whose elements are indirectly - accessed. Elements of such types may have components of their own type, may have - substructure that can be altered during execution, and may be distinct while having - identical component values. Such types shall be distinguishable from other composite - types in their definitions. An element of an indirect type shall remain allocated as - long as it can be referenced by the program. [Note that indirect types require pointers - and sometimes heap storage in their implementation.] - yesyesyesyes
-
- 3-3J. Operations on Indirect Types. Each execution of the constructor operation for an - indirect type shall create a distinct element of the type. An operation that - distinguishes between different elements, an operation that replaces all of the - component values of an element without altering the element's identity, and an operation - that produces a new element having the same component values as its argument, shall be - automatically defined for each indirect type. - yesyesyesyes
-
- 3-4A. Bit Strings (i.e., Set Types). It shall be possible to define types whose elements - are one-dimensional Boolean arrays represented in maximally packed form (i.e, whose - elements are sets). - yesyesyespartial
- D provides bit arrays in the standard library in std.bitmanip. It is easy enough to - construct bit strings in Rust using structs or integer types, but the language itself - does not provide them as built in functionality. -
- 3-4B. Bit String Operations. Set construction, membership (i.e., subscription), set - equivalence and nonequivalence, and also complement, intersection, union, and symmetric - difference (i.e., component-by-component negation, conjunction, inclusive disjunction, - and exclusive disjunction respectively) operations shall be defined automatically for - each set type. - yesyes?yespartial
-
- 3-5A. Encapsulated Definitions. It shall be possible to encapsulate definitions. An - encapsulation may contain declarations of anything (including the data elements and - operations comprising a type) that is definable in programs. The language shall permit - multiple explicit instantiations of an encapsulation. - yesyesyesyes
- All of these languages have modules as their unit of encapsulation. -
- 3-5B. Effect of Encapsulation. An encapsulation may be used to inhibit external access - to implementation properties of the definition. In particular, it shall be possible to - prevent external reference to any declaration within the encapsulation including - automatically defined operations such as type conversions and equality. Definitions that - are made within an encapsulation and are externally accessible may be renamed before use - outside the encapsulation. - yesyesyesyes
-
- 3-5C. Own Variables. Variables declared within an encapsulation, but not within a - function, procedure, or process of the encapsulation, shall remain allocated and retain - their values throughout the scope in which the encapsulation is instantiated. - yesyesyesyes
-
- 4A. Form of Expressions. The parsing of correct expressions shall not depend on the - types of their operands or on whether the types of the operands are built into the - language. - yesyesyesyes
-
- 4B. Type of Expressions. It shall be possible to specify the type of any expression - explicitly. The use of such specifications shall be required only where the type of the - expression cannot be uniquely determined during translation from the context of its use - (as might be the case with a literal). - yesyesyesyes
-
- 4C. Side Effects. The language shall attempt to minimize side effects in expressions, - but shall not prohibit all side effects. A side effect shall not be allowed if it would - alter the value of a variable that can be accessed at the point of the expression. Side - effects shall be limited to own variables of encapsulations. The language shall permit - side effects that are necessary to instrument functions and to do storage management - within functions. The order of side effects within an expression shall not be - guaranteed. [Note that the latter implies that any program that depends on the order of - side effects is erroneous.] - mostly?yes?mostly?mostly?
- Parasail does not permit global variables. -
- 4D. Allowed Usage. Expressions of a given type shall be allowed wherever both constants - and variables of the type are allowed. - yesyesyesyes
-
- 4E. Translation Time Expressions. Expressions that can be evaluated during translation - shall be permitted wherever literals of the type are permitted. Translation time - expressions that include only literals and the use of translation time facilities (see - 11C) shall be evaluated during translation. - yesyesyesyes
-
- 4F. Operator Precedence Levels. The precedence levels (i.e., binding strengths) of all - (prefix and infix) operators shall be specified in the language definition, shall not be - alterable by the user, shall be few in number, and shall not depend on the types of the - operands. - mostlyyesyesmostly
- Pascal has 5 levels, Parasail has 7, Rust has 13 and D has 15-19 depending on how you - count them. For comparison, Ada has 6. -
- 4G. Effect of Parentheses. If present, explicit parentheses shall dictate the - association of operands with operators. The language shall specify where explicit - parentheses are required and shall attempt to minimize the psychological ambiguity in - expressions. [Note that this might be accomplished by requiring explicit parentheses to - resolve the operator-operand association whenever a nonassociative operator appears to - the left of an operator of the same precedence at the least-binding precedence level of - any subexpression.] - yesyesyesyes
-
- 5A. Declarations of Constants. It shall be possible to declare constants of any type. - Such constants shall include both those whose values-are determined during translation - and those whose value cannot be determined until allocation. Programs may not assign to - constants. - yesyesyesyes
-
- 5B. Declarations of Variables. Each variable must be declared explicitly. Variables may - be of any type. The type of each variable must be specified as part of its declaration - and must be determinable during translation. [Note, "variable" throughout this document - refers not only to simple variables but also to composite variables and to components of - arrays and records.] - mostlyyesyespartial
- D permits "void *" as a type, which is really a pointer to an unknown type and subverts - the type system. Rust does not require the type of each variable to be explicitly - specified and will infer types instead. -
- 5C. Scope of Declarations. Everything (including operators) declared in a program shall - have a scope (i.e., a portion of the program in which it can be referenced). Scopes - shall be determinable during translation. Scopes may be nested (i.e., lexically - embedded). A declaration may be made in any scope. Anything other than a variable shall - be accessable within any nested scope of its definition. - yes?yesyesyes?
-
- 5D. Restrictions on Values. Procedures, functions, types, labels, exception situations, - and statements shall not be assignable to variables, be computable as values of - expressions, or be usable as nongeneric parameters to procedures or functions. - nonono?no
- D and Pascal allow pointers to functions. Parasail allows lambda expressions. Rust has - first class functions. -
- 5E. Initial Values. There shall be no default initial-values for variables. - partialpartialpartial?mostly
- D defines initial values for all types. Parasail sets initial values of all 'optional' - types to null. Rust does not assign default initial values, but instead requires the - programmer to always provide an initial value. All of these instances are done to - support reliability. -
- 5F. Operations on Variables. Assignment and an implicit value access operation shall be - automatically defined for each variable. - yesyesyesyes
-
- 5G. Scope of Variables. The language shall distinguish between open scopes (i.e., those - that are automatically included in the scope of more globally declared variables) and - closed scopes (i.e., those in which nonlocal variables must be explicitly Imported). - Bodies of functions, procedures, and processes shall be closed scopes. Bodies of - classical control structures shall be open scopes. - yesyesyesyes
-
- 6A. Basic Control Facility. The (built-in) control mechanisms should be of minimal - number and complexity. Each shall provide a single capability and shall have a - distinguishing syntax. Nesting of control structures shall be allowed. There shall be no - control definition facility. Local scopes shall be allowed within the bodies of control - statements. Control structures shall have only one entry point and shall exit to a - single point unless exited via an explicit transfer of control (where permitted, see - 6G), or the raising of an exception (see 10C). - yesyesyesyes
-
- 6B. Sequential Control. There shall be a control mechanism for sequencing statements. - The language shall not impose arbitrary restrictions on programming style, such as the - choice between statement terminators and statement separators, unless the restriction - makes programming errors less likely. - yesyesyesyes
- D and Rust use statement terminators. Pascal and Parasail use statement separators. -
- 6C. Conditional Control. There shall be conditional control structures that permit - selection among alternative control paths. The selected path may depend on the value of - a Boolean expression, on a computed choice among labeled alternatives, or on the true - condition in a set of conditions. The language shall define the control action for all - values of the discriminating condition that are not specified by the program. The user - may supply a single control path to be used when no other path is selected. Only the - selected branch shall be compiled when the discriminating condition is a translation - time expression. - yesyesyesyes
-
- 6D. Short Circuit Evaluation. There shall be infix control operations for short circuit - conjunction and disjunction of the controlling Boolean expression in conditional and - iterative control structures. - yesyespartialyes
- Standard Pascal does not provide infix control operations, but both Extended Pascal and - Turbo Pascal do. -
- 6E. Iterative Control. There shall be an iterative control structure. The iterative - control may be exited (without reentry) at an unrestricted number of places. A - succession of values from an enumeration type or the integers may be associated with - successive iterations and the value for the current iteration accessed as a constant - throughout the loop body. - mostlyyesyesyes
- In D, the loop control variable is not considered a constant. -
- 6G. Explicit Control Transfer. There shall be a mechanism for control transfer (i.e., - the go to). It shall not be possible to transfer out of closed scopes, into narrower - scopes, or into control structures. It shall be possible to transfer out of classical - control structures. There shall be no control transfer mechanisms in the form of - switches, designational expressions, label variables, label parameters, or alter - statements. - yes?partialyespartial?
- Neither Parasail nor Rust support goto. However both support break/continue statements - that serve the same purpose in many cases. -
- 7A. Function and Procedure Definitions. Functions (which return values to expressions) - and procedures (which can be called as statements) shall be definable in programs. - Functions or procedures that differ in the number or types of their parameters may be - denoted by the same identifier or operator (i.e., overloading shall be permitted). [Note - that redefinition, as opposed to overloading, of an existing function or procedure is - often error prone.] - yesyesyesno
- Rust does not support ad-hoc polymorphism. It must be emulated using the trait system. -
- 7B. Recursion. It shall be possible to call functions and procedures recursively. - yesyesyesyes
-   -
- 7C. Scope Rules. A reference to an identifier that is not declared in the most local - scope shall refer to a program element that is lexically global, rather than to one that - is global through the dynamic calling structure. - yesyesyesyes
-
- 7D. Function Declarations. The type of the result for each function must be specified in - its declaration and shall be determinable during translation. The results of functions - may be of any type. If a result is of a nonindirect array or record type then the number - of its components must be determinable by the time of function call. - mostlymostlymostly?mostly
-
- 7F. Formal Parameter Classes. There shall be three classes of formal data parameters: - (a) input parameters, which act as constants that are initialized to the value of - corresponding actual parameters at the time of call, (b) input-output parameters, which - enable access and assignment to the corresponding actual parameters, either throughout - execution or only upon call and prior to any exit, and (c) output parameters, whose - values are transferred to the corresponding actual parameter only at the time of normal - exit. In the latter two cases the corresponding actual parameter shall be determined at - time of call and must be a variable or an assignable component of a composite type. - partialyespartial?partial?
- D, Pascal and Rust do not identify in, in-out and out parameters. D, Pascal and Rust can - support in-only parameters. -
- 7G. Parameter Specifications. The type of each formal parameter must be explicitly - specified in programs and shall be determinable during translation. Parameters may be of - any type. The language shall not require user specification of subtype constraints for - formal parameters. If such constraints are permitted they shall be interpreted as - assertions and not as additional overloading. Corresponding formal and actual parameters - must be of the same type. - yes?yesyesyes?
-
- 7H. Formal Array Parameters. The number of dimensions for formal array parameters must - be specified in programs and shall be determinable during translation. Determination of - the subscript range for formal array parameters may be delayed until invocation and may - vary from call to call. Subscript ranges shall be accessible within function and - procedure bodies without being passed as explicit parameters. - noyesyesno
- Subscript ranges are not accessible in D or Rust. -
- 7I. Restrictions to Prevent Aliasing. The language shall attempt to prevent aliasing - (i.e., multiple access paths to the same variable or record component) that is not - intended, but shall not prohibit all aliasing. Aliasing shall not be permitted between - output parameters nor between an input-output parameter and a nonlocal variable. - Unintended aliasing shall not be permitted between input-output parameters. A - restriction limiting actual input-output parameters to variables that are nowhere - referenced as nonlocals within a function or routine, is not prohibited. All aliasing of - components of elements of an indirect type shall be considered intentional. - noyesyes?yes
-
- 8A. Low Level Input-Output. There shall be a few low level input-output operations that - send and receive control information to and from physical channels and devices. The low - level operations shall be chosen to insure that all user level input-output operations - can be defined within the language. - partial?no?partial?no?
- D and some Pascal dialects permit access to memory mapped locations. -
- 8B. User Level Input-Output. The language shall specify (i.e., give calling format and - general semantics) a recommended set of user level input-output operations. These shall - include operations to create, delete, open, close, read, write, position, and - interrogate both sequential and random access files and to alter the association between - logical files and physical devices. - yesyesyesyes
-
- 8C. Input Restrictions. User level input shall be restricted to data whose record - representations are known to the translator (i.e., data that is created and written - entirely within the program or data whose representation is explicitly specified in the - program). - yesyesyesyes
-
- 8D. Operating System Independence. The language shall not require the presence of an - operating system. [Note that on many machines it will be necessary to provide run-time - procedures to implement some features of the language.] - yesyesyesyes
-
- 8E. Resource Control. There shall be a few low level operations to interrogate and - control physical resources (e.g., memory or processors) that are managed (e.g., - allocated or scheduled) by built-in features of the language. - mostlymostlypartialno
- D supports custom garbage collection and thread priorities. Standard Pascal does not - define ways to control physical resources, but popular implementations such as Free - Pascal provide both custom memory management and thread facilities. -
- 8F. Formating. There shall be predefined operations to convert between the symbolic and - internal representation of all types that have literal forms in the language (e.g., - strings of digits to integers, or an enumeration element to its symbolic form). These - conversion operations shall have the same semantics as those specified for literals in - programs. - yesyesyespartial
- In Rust, operations to convert between enumerations and strings are not predefined. -
- 9A. Parallel Processing. It shall be possible to define parallel processes. Processes - (i.e., activation instances of such a definition) may be initiated at any point within - the scope of the definition. Each process (activation) must have a name. It shall not be - possible to exit the scope of a process name unless the process is terminated (or - uninitiated). - yesmostlynoyes
- D provides this functionality with the std.parallelism and core.thread libraries. Rust - provides this with the std::thread library. Parasail is designed to be implicitly - parallel by default, and thus the lightweight threads used do not have names. Pascal - does not have built in thread or process facilities, and must rely on operating system - specific libraries. -
- 9B. Parallel Process Implementation. The parallel processing facility shall be designed - to minimize execution time and space. Processes shall have consistent semantics whether - implemented on multicomputers, multiprocessors, or with interleaved execution on a - single processor. - yesyesnoyes
-
- 9C. Shared Variables and Mutual Exclusion. It shall be.possible to mark variables that - are shared among parallel processes. An unmarked variable that is assigned on one path - and used on another shall cause a warning. It shall be possible efficiently to perform - mutual exclusion in programs. The language shall not require any use of mutual - exclusion. - partial?yesnoyes
- D supports shared variables and atomic operations, however the idiomatic way of - threading is to rely on immutable data and message passing. -
- 9D. Scheduling. The semantics of the built-in scheduling algorithm shall be - first-in-first-out within priorities. A process may alter its own priority. If the - language provides a default priority for new processes it shall be the priority of its - initiating process. The built-in scheduling algorithm shall not require that - simultaneously executed processes on different processors have the same priority. [Note - that this rule gives maximum scheduling control to the user without loss of efficiency. - Note also that priority specification does not impose a specific execution order among - parallel paths and thus does not provide a means for mutual exclusion.] - yes?yes?nopartial?
-
- 9E. Real Time. It shall be possible to access a real time clock. There shall be - translation time constants to convert between the implementation units and the program - units for real time. On any control path, it shall be possible to delay until at least a - specified time before continuing execution. A process may have an accessible clock - giving the cumulative processing time (i.e., CPU time) for that process. - yesyesyes?yes?
- D provides this in core.time. Parasail provides this in its standard library. -
- 9G. Asynchronous Termination. It shall be possible to terminate another process. The - terminated process may designate the sequence of statements it will execute in response - to the induced termination. - yesno?noyes
- D achieves this with std.parallelism and std.process. Pascal programs call an operating - system dependent library to perform this. Parasail is structured around implicit - pervasive parallelism so it's questionable how applicable this requirement is. Rust - achieves this with std::process::Child. -
- 9H. Passing Data. It shall be possible to pass data between processes that do not share - variables. It shall be possible to delay such data transfers until both the sending and - receiving processes have requested the transfer. - yesyesnoyes
- D synchronized calls allow this. Rust achieves this with std::sync::mpsc. -
- 9I. Signalling. It shall be possible to set a signal (without waiting), and to wait for - a signal (without delay, if it is already set). Setting a signal, that is not already - set, shall cause exactly one waiting path to continue. - mostly?mostly?nomostly?
-
- 9J. Waiting. It shall be possible to wait for, determine, and act upon the first - completed of several wait operations (including those used for data passing, signalling, - and real time). - mostly?mostly?nomostly?
-
- 10A. Exception Handling Facility. There shall be an exception handling mechanism for - responding to unplanned error situations detected in declarations and statements during - execution. The exception situations shall include errors detected by hardware, software - errors detected during execution, error situations in built-in operations, and user - defined exceptions. Exception identifiers shall have a scope. Exceptions should add to - the execution time of programs only if they are raised. - yespartial?partial?partial
- Standard Pascal does not specify how to treat errors, whether with exceptions or - otherwise. However later variations including FreePascal and Delphi support exceptions. - Parasail attempts to check for all possible errors at compile time, however it is - unclear from the reference manual how hardware problems are handled. Rust opts for using - return value types to show errors rather than exceptions. -
- 10B. Error Situations. The errors detectable during execution shall include exceeding - the specified range of an array subscript, exceeding the specified range of a variable, - exceeding the implemented range of a variable, attempting to access an uninitialized - variable, attempting to access a field of a variant that is not present, requesting a - resource (such as stack or heap storage) when an insufficient quantity remains, and - failing to satisfy a program specified assertion. [Note that some are very expensive to - detect unless aided by special hardware, and consequently their detection will often be - suppressed (see 10G).] - partial?mostlypartialpartial?
- Parasail is constructed to detect all of these mentioned errors, except the out of - memory error, at compile time. -
- 10C. Raising Exceptions. There shall be an operation that raises an exception. Raising - an exception shall cause transfer of control to the most local enclosing exception - handler for that exception without completing execution of the current statement or - declaration, but shall not of itself cause transfer out of a function, procedure, or - process. Exceptions that are not handled within a function or procedure shall be raised - again at the point of call in their callers. Exceptions that are not handled within a - process shall terminate the process. Exceptions that can be raised by built-in - operations shall be given in the language definition. - yespartialpartialpartial
- Standard Pascal does not specify how to handle errors, whether exceptions or otherwise, - see 10A. It is unclear from the Parasail reference manual whether actual exceptions are - used in the language, but similar functionality is achieved with compile time - annotations. Rust opts for using return value types to show errors rather than - exceptions. Various functions and macros are provided that more or less covers the same - thing, but not in a way that satisfies this requirement. -
- 10D. Exception Handling. There shall be a control structure for discriminating among the - exceptions that can occur in a specified statement sequence. The user may supply a - single control path for all exceptions not otherwise mentioned in such a discrimination. - It shall be possible to raise the exception that selected the current handler when - exiting the handler. - yesno?partialno
- Standard Pascal does not specify how to handle errors, whether exceptions or otherwise, - see 10A. -
- 10E. Order of Exceptions. The order in which exceptions in different parts of an - expression are detected shall not be guaranteed by the language or by the translator. - yes?yesyesyes
-
- 10F. Assertions. It shall be possible to include assertions in programs. If an assertion - is false when encountered during execution, it shall raise an exception. It shall also - be possible to include assertions, such as the expected frequency for selection of a - conditional path, that cannot be verified. [Note that assertions can be used to aid - optimization and maintenance.] - mostlymostlynomostly
- None? of these languages permit assertions of frequency. -
- 10G. Suppressing Exceptions. It shall be possible during translation to suppress - individually the execution time detection of exceptions within a given scope. The - language shall not guarantee the integrity of the values produced when a suppressed - exception occurs. [Note that suppression of an exception is not an assertion that the - corresponding error will not occur.] - partialnonono
- It is possible to statically disallow code from throwing exceptions in D, but that - doesn't fulfil the same function as this requirement. -
- 11A. Data Representation. The language shall permit but not require programs to specify - a single physical representation for the elements of a type. These specifications shall - be separate from the logical descriptions. Physical representation shall include object - representation of enumeration elements, order of fields, width of fields, presence of - "don't care" fields, positions of word boundaries, and object machine addresses. In - particular, the facility shall be sufficient to specify the physical representation of - any record whose format is determined by considerations that are entirely external to - the program, translator, and language. The language and its translators shall not - guarantee any particular choice for those aspects of physical representation that are - unspecified by the program. It shall be possible to specify the association of physical - resources (e.g., interrupts) to program elements (e.g., exceptions or signals). - partial?no?nopartial
-
- 11C. Translation Time Facilities. To aid conditional compilation, it shall be possible - to interrogate properties that are known during translation including characteristics of - the object configuration, of function and procedure calling environments, and of actual - parameters. For example, it shall be possible to determine whether the caller has - suppressed a given exception, the callers optimization criteria, whether an actual - parameter is a translation time expression, the type of actual generic parameters, and - the values of constraints characterizing the subtype of actual parameters. - partialpartial?nopartial
-
- 11D. Object System Configuration. The object system configuration must be explicitly - specified in each separately translated unit. Such specifications must include the - object machine model, the operating system if present, peripheral equipment, and the - device configuration, and may include special hardware options and memory size. The - translator will use such specifications when generating object code. [Note that programs - that depend on the specific characteristics of the object machine, may be made more - portable by enclosing those portions in branches of conditionals on the object machine - configuration.] - no?no?nono?
-
- 11E. Interface to Other Languages. There shall be a machine independent interface to - other programming languages including assembly languages. Any program element that is - referenced in both the source language program and foreign code must be identified in - the interface. The source language of the foreign code must also be identified. - yesnomostlyyes
- D provides interfaces to C, C++ and assembly. Many Pascal implementations provide - interfaces to C and assembly. Parasail provides no interfaces to other languages. Rust - provides an interface to C and assembly. -
- 11F. Optimization. Programs may advise translators on the optimization criteria to be - used in a scope. It shall be possible in programs to specify whether minimum translation - costs or minimum execution costs are more important, and whether execution time or - memory space is to be given preference. All such specifications shall be optional. - Except for the amount of time and space required during execution, approximate values - beyond the specified precision, the order in which exceptions are detected, and the - occurrence of side effects within an expression, optimization shall not alter the - semantics of correct programs, (e.g., the semantics of parameters will be unaffected by - the choice between open and closed calls). - partial?no?partial?partial?
-
- 12A. Library. There shall be an easily accessible library of generic definitions and - separately translated units. All predefined definitions shall be in the library. Library - entries may include those used as input-output packages, common pools of shared - declarations, application oriented software packages, encapsulations, and machine - configuration specifications. The library shall be structured to allow entries to be - associated with particular applications, projects, and users. - yesyesyesyes
-
- 12B. Separately Translated Units. Separately translated units may be assembled into - operational systems. It shall be possible for a separately translated unit to reference - exported definitions of other units. All language imposed restrictions shall be enforced - across such interfaces. Separate translation shall not change the semantics of a correct - program. - mostly?yes?yes?yes?
-
- 12D. Generic Definitions. Functions, procedures, types, and encapsulations may have - generic parameters. Generic parameters shall be instantiated during translation and - shall be interpreted in the context of the instantiation. An actual generic parameter - may be any defined identifier (including those for variables, functions, procedures, - processes, and types) or the value of any expression. - yesyespartialmostly
- Rust only accepts types as generic parameters. Standard Pascal does not support - generics, but later Pascal derivatives such as Free Pascal and Delphi both do. -
- 13A. Defining Documents. The language shall have a complete and unambiguous defining - document. It should be possible to predict the possible actions of any syntactically - correct program from the language definition. The language documentation shall include - the syntax, semantics, and appropriate examples of each built-in and predefined feature. - A recommended set of translation diagnostic and warning messages shall be included in - the language definition. - mostly?mostly?yespartial
-
- 13B. Standards. There will be a standard definition of the language. Procedures will be - established for standards control and for certification that translators meet the - standard. - nonoyesno
-
- 13C. Completeness of Implementations. Translators shall implement the standard - definition. Every translator shall be able to process any syntactically correct program. - Every feature that is available to the user shall be defined in the standard, in an - accessible library, or in the source program. - mostly?yesyesmostly
-
- 13D. Translator Diagnostics. Translators shall be responsible for reporting errors that - are detectable during translation and for optimizing object code. Translators shall be - responsible for the integrity of object code in affected translation units when any - separately translated unit is modified, and shall ensure that shared definitions have - compatible representations in all translation units. Translators shall do full syntax - and type checking, shall check that all language imposed restrictions are met, and - should provide warnings where constructs will be dangerous or unusually expensive in - execution and shall attempt to detect exceptions during translation. If the translator - determines that a call on a routine will not terminate normally, the exception shall be - reported as a translation error at the point of call. - mostly?yesyes?yes?
-
- 13E. Translator Characteristics. Translators for the language will be written in the - language and will be able to produce code for a variety of object machines. The machine - independent parts of translators should be separate from code generators. Although it is - desirable, translators need not be able to execute on every object machine. The internal - characteristics of the translator (i.e., the translation method) shall not be specified - by the language definition or standards. - mostlymostlymostlymostly
- Many, but not all, compilers are written in their own language. Parasail and Rust both - have one compiler each, both written in their respective language. -
- 13F. Restrictions on Translators. Translators shall fail to translate otherwise correct - programs only when the program requires more resources during translation than are - available on the host machine or when the program calls for resources that are - unavailable in the specified object system configuration. Neither the language nor its - translators shall impose arbitrary restrictions on language features. For example, they - shall not impose restrictions on the number of array dimensions, on the number of - identifiers, on the length of identifiers, or on the number of nested parentheses - levels. - yesyesyes?yes
-
- 13G. Software Tools and Application Packages. The language should be designed to work in - conjunction with a variety of useful software tools and application support packages. - These will be developed as early as possible and will include editors, interpreters, - diagnostic aids, program analyzers, documentation aids, testing aids, software - maintenance tools, optimizers, and application libraries. There will be a consistent - user interface for these tools. Where practical software tools and aids will be written - in the language. Support for the design, implementation, distribution, and maintenance - of translators, software tools and aids, and application libraries will be provided - independently of the individual projects that use them. - mostlypartialyespartial
-
- -
-
-{% endblock -%} - - -- cgit