diff options
Diffstat (limited to 'project/templates/steelman.html')
| -rw-r--r-- | project/templates/steelman.html | 2437 |
1 files changed, 0 insertions, 2437 deletions
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 %} - <link href="/css/steelman.css" rel="stylesheet" /> -{% endblock -%} - - - -{%- block content %} -<h4>D, Parasail, Pascal, and Rust vs The Steelman</h4> - -<h5>29/10/2017</h5> - - -<h5>Overview</h5> - -<p>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. -</p> - -<p>In 1996 David A. Wheeler <a href="http://www.adahome.com/History/Steelman/steeltab.htm" -class="external">wrote a paper</a> 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.</p> - - -<h5>The Languages</h5> - -<p><a href="https://dlang.org/" class="external">D</a> 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.</p> - -<p><a href="https://forge.open-do.org/plugins/moinmoin/parasail/" class="external">Parasail</a> 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, <a href="https://www.embedded.com/design/programming-languages-and-tools/4375616/1/ParaSail--Less-is-more-with-multicore" -class="external">simplifying and adding static checking</a> to eliminate as many sources of errors -as possible. It represents a possible future direction for Ada derived languages.</p> - -<p><a href="https://en.wikipedia.org/wiki/Pascal_(programming_language)" class="external">Pascal -</a>, 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 -<a href="https://www.tutorialspoint.com/pascal/pascal_overview.htm" class="external">teaching -algorithms</a>. 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.</p> - -<p><a href="https://www.rust-lang.org/" class="external">Rust</a> 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 <a href="https://en.wikipedia.org/wiki/Substructural_type_system" -class="external">affine typing</a>.</p> - -<table id="lang"> - <tr> - <td> - <div class="figure"> - <img src="/img/logo_d_small.png" - alt="Logo for the D programming language" - height="124" - width="164" /> - <div class="figcaption">D</div> - </div> - </td> - <td> - <div class="figure"> - <img src="/img/logo_parasail_small.png" - alt="Logo for the Parasail programming language" - height="144" - width="149" /> - <div class="figcaption">Parasail</div> - </div> - </td> - </tr> - <tr> - <td> - <div class="figure"> - <img src="/img/logo_pascal_small.png" - alt="A picture of Blaise Pascal to stand in as a logo for the Pascal programming language" - height="144" - width="142" /> - <div class="figcaption">Pascal*</div> - </div> - </td> - <td> - <div class="figure"> - <img src="/img/logo_rust_small.png" - alt="Logo for the Rust programming language" - height="144" - width="144" /> - <div class="figcaption">Rust</div> - </div> - </td> - </tr> -</table> - -<p>* Pascal does not have an official logo, so a picture of -<a href="https://en.wikipedia.org/wiki/Blaise_Pascal" class="external">Blaise Pascal</a>, in whose -honour the language is named, will have to do.</p> - - -<h5>Rules for Comparison</h5> - -<p>The rule used for this article is that a language provides a feature if:</p> -<ol> - <li>that feature is defined in the documents widely regarded as the language's defining - document(s), <b>or</b></li> - <li>that feature is widely implemented by compilers typically used for that language with - essentially the same semantics.</li> -</ol> - -<p>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.</p> - -<p>The defining documents used for each of these languages are as follows:</p> -<ul> - <li>D: The <a href="https://dlang.org/spec/spec.html" class="external">D Language - Specification</a> and the accompanying <a href="https://dlang.org/phobos/index.html" - class="external">Library Reference</a>.</li> - <li>Parasail: The <a href="https://forge.open-do.org/plugins/moinmoin/parasail/FrontPage?action=AttachFile&do=view&target=parasail_ref_manual.pdf" - class="external">Parasail Reference Manual</a>. Parasail is still a work in progress, and no - efforts to standardise it have yet been started.</li> - <li>Pascal: ISO 7185 details Standard Pascal, and is available at several places in various - formats. The copy used here was retrieved from <a href="http://www.pascal-central.com/standards.html" - class="external">Pascal Central</a>. Checking for features of more recent Pascal dialects is - done on a more ad hoc basis.</li> - <li>Rust: The closest there is to a definition of the language is given in - <a href="https://doc.rust-lang.org/reference/" class="external">The Rust Reference</a>. It - should be noted that this document is not complete, nor stable. Supplementary information was - obtained from <a href="https://rustbyexample.com/" class="external">Rust by Example</a>. No work - to standardise Rust has been started yet either.</li> -</ul> - - -<h5>Results and Conclusions</h5> - -<p>The appendix lists the Steelman requirements and how well each language supports them. The -following table shows a summary:</p> - -<table id="results"> - <tr> - <th>Language</th> - <th>"No"</th> - <th>"Partial"</th> - <th>"Mostly"</th> - <th>"Yes"</th> - <th>Percentage with "Mostly" or "Yes"</th> - </tr> - <tr> - <td>D</td> - <td>7</td> - <td>15</td> - <td>25</td> - <td>66</td> - <td>81%</td> - </tr> - <tr> - <td>Parasail</td> - <td>11</td> - <td>6</td> - <td>11</td> - <td>85</td> - <td>85%</td> - </tr> - <tr> - <td>Pascal</td> - <td>19</td> - <td>16</td> - <td>11</td> - <td>67</td> - <td>69%</td> - </tr> - <tr> - <td>Rust</td> - <td>12</td> - <td>19</td> - <td>23</td> - <td>59</td> - <td>73%</td> - </tr> -</table> - -<p>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.</p> - -<p>The following are high level comments on these programming languages and how they relate:</p> -<ul> - <li>All of these languages suffer from either not being standardised or, in the case of Pascal, - having fragmented into multiple non-standard dialects afterwards. This impacts their scores for - requirements 1H, 13A, 13B.</li> - <li>Requirements 2A, 5D, 5E are perhaps not suitable to apply to today's programming languages, - due to the presence of Unicode, functional programming, and use of initial values for safety - guarantees respectively.</li> - <li>Parasail scores very well on the Steelman, as expected from its Ada heritage and Ada having - been explicitly designed to fit these requirements. Most of the "no" and "partial" items for - Parasail are due to the lack of low level interfaces and pragmas (likely due to its experimental - nature) and due to the pervasive implicit parallelism and increased static guarantees.</li> - <li>D does significantly better than C, C++, or Java from the previous comparison due to the - inclusion of new features such as parallelism into the language. Contracts in particular allow - the subtyping requirements 3B, 3C, 3D to be at least partially satisfied. Most of its failures - here can be attributed to its C legacy, including syntax, grammar, number of operator precedence - levels, pointers, primitive type flexibility, and integer overflow handling. Noteworthy is the - lack of a preprocessor.</li> - <li>Pascal, at least the ISO standard variety, does not support parallelism and leaves a lot of - error handling and floating point details up to implementation. Nonetheless its syntax, grammar, - and more expressive type system (aside from the well known string length issue) contribute to - its higher score compared to C.</li> - <li>Rust lacks subtyping or contracts to emulate the requirements 3B, 3D, and its use of return - values instead of exceptions leads to lower scores on 10A through 10G. The syntax is already - notorious and the presence of macros may cause further issues. But it is definitely a - significant improvement on C with an emphasis on immutability from its functional roots. The - central failure of the language is the myopic focus on the affine typing solution to heap - allocation and thread safety. The creators do not seem to realise that other solutions already - exist, and that dynamic memory allocation is not the only safety issue a programmer has to cope - with.</li> - <li>Parasail and Ada remain the only languages so far considered that support fixed point types - in the core language.</li> - <li>Rust has by far the most support for the functional programming paradigm.</li> -</ul> - - -<h5>Appendix: Table Comparing the Languages to Steelman</h5> - -<p>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.</p> - -<p>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.</p> - - -<div class="accordian"> - <input type="checkbox" name="collapse" id="handle1" /> - <label for="handle1">Toggle Appendix Table</label> - <div class="hidden_content"> - -<table id="appendix"> - <tr> - <th style="width: 30em">Requirement</th> - <th style="width: 7.5em">D</th> - <th style="width: 7.5em">Parasail</th> - <th style="width: 7.5em">Pascal</th> - <th style="width: 7.5em">Rust</th> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">no?</td> - <td class="yn">yes?</td> - <td class="yn">yes?</td> - </tr> - <tr> - <td colspan="4"> - Parasail does not specify ways to directly control hardware, nor any interfaces to other - languages. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes?</td> - <td class="yn">yes</td> - <td class="yn">partial?</td> - <td class="yn">mostly?</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">partial?</td> - <td class="yn">yes?</td> - <td class="yn">mostly?</td> - <td class="yn">partial?</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">partial?</td> - <td class="yn">yes?</td> - <td class="yn">yes</td> - <td class="yn">yes?</td> - </tr> - <tr> - <td colspan="4"> - D incorporates garbage collection to some extent. Parasail is designed to allow as much - implicit parallelism as possible. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes?</td> - <td class="yn">mostly</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - Parasail allows several syntactical forms that are identical in meaning. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - All of these languages have been reasonably implemented. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">mostly?</td> - <td class="yn">mostly?</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly</td> - <td class="yn">mostly</td> - <td class="yn">mostly</td> - <td class="yn">mostly</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">partial?</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">partial?</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">no</td> - </tr> - <tr> - <td colspan="4"> - Rust has macros, which can be used to add new syntax to the language. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly</td> - <td class="yn">yes</td> - <td class="yn">mostly</td> - <td class="yn">mostly</td> - </tr> - <tr> - <td colspan="4"> - D, Pascal, and Rust permit multi line comments. D and Rust use opening and closing - braces rather than key words. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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.) - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 2G. Numeric Literals. There shall be built-in decimal literals. There shall be no - implicit truncation or rounding of integer and fixed point literals. - </td> - <td class="yn">mostly</td> - <td class="yn">yes</td> - <td class="yn">mostly?</td> - <td class="yn">mostly</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - Univ_Strings in Parasail are vectors of Univ_Character, not arrays. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">partial</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - Line comments were introduced in Turbo Pascal, but are not part of the ISO standard. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">partial?</td> - <td class="yn">yes</td> - <td class="yn">yes?</td> - <td class="yn">partial?</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly</td> - <td class="yn">yes</td> - <td class="yn">yes?</td> - <td class="yn">mostly</td> - </tr> - <tr> - <td colspan="4"> - D, Rust do not have subtypes. D however can emulate similar functionality with type - invariant contracts for user defined classes. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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.] - </td> - <td class="yn">partial</td> - <td class="yn">yes?</td> - <td class="yn">mostly?</td> - <td class="yn">no</td> - </tr> - <tr> - <td colspan="4"> - D does not have subtypes but has similar functionality with class type invariants. Rust - doesn't have subtypes at all. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">partial?</td> - <td class="yn">yes</td> - <td class="yn">partial?</td> - <td class="yn">mostly?</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly</td> - <td class="yn">yes</td> - <td class="yn">mostly</td> - <td class="yn">mostly</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly</td> - <td class="yn">yes</td> - <td class="yn">no</td> - <td class="yn">mostly</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes?</td> - <td class="yn">partial</td> - <td class="yn">yes?</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly</td> - <td class="yn">yes</td> - <td class="yn">partial</td> - <td class="yn">mostly</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">no</td> - <td class="yn">yes</td> - <td class="yn">no</td> - <td class="yn">no</td> - </tr> - <tr> - <td colspan="4"> - Of these four languages, only Parasail supports fixed point types. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">no</td> - <td class="yn">yes</td> - <td class="yn">no</td> - <td class="yn">no</td> - </tr> - <tr> - <td colspan="4"> - All support "modulo" operators; D, Pascal, Rust don't support fixed point numbers. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">mostly</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes?</td> - <td class="yn">yes?</td> - <td class="yn">mostly?</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 3-2C. Boolean Type. There shall be a predefined type for Boolean values. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - D's boolean type is weakly typed. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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). - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - All have arrays and records. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - Range, precision, and scale specifications are included in numeric type definitions - (with support varying, see 3-1). - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">mostly</td> - </tr> - <tr> - <td colspan="4"> - D and Rust array indexes can only start at zero and cannot use enumerations. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes?</td> - <td class="yn">no</td> - <td class="yn">partial</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">no?</td> - <td class="yn">no?</td> - </tr> - <tr> - <td colspan="4"> - D classes can include constants and functions. Parasail type inferfaces can include - constants and functions. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes?</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - 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". - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes?</td> - <td class="yn">yes?</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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.] - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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). - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">partial</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes?</td> - <td class="yn">yes</td> - <td class="yn">partial</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - All of these languages have modules as their unit of encapsulation. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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). - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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.] - </td> - <td class="yn">mostly?</td> - <td class="yn">yes?</td> - <td class="yn">mostly?</td> - <td class="yn">mostly?</td> - </tr> - <tr> - <td colspan="4"> - Parasail does not permit global variables. - </td> - </tr> - - <tr> - <td rowspan="2"> - 4D. Allowed Usage. Expressions of a given type shall be allowed wherever both constants - and variables of the type are allowed. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">mostly</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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.] - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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.] - </td> - <td class="yn">mostly</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">partial</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes?</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes?</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">no</td> - <td class="yn">no</td> - <td class="yn">no?</td> - <td class="yn">no</td> - </tr> - <tr> - <td colspan="4"> - D and Pascal allow pointers to functions. Parasail allows lambda expressions. Rust has - first class functions. - </td> - </tr> - - <tr> - <td rowspan="2"> - 5E. Initial Values. There shall be no default initial-values for variables. - </td> - <td class="yn">partial</td> - <td class="yn">partial</td> - <td class="yn">partial?</td> - <td class="yn">mostly</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 5F. Operations on Variables. Assignment and an implicit value access operation shall be - automatically defined for each variable. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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). - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - D and Rust use statement terminators. Pascal and Parasail use statement separators. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">partial</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - Standard Pascal does not provide infix control operations, but both Extended Pascal and - Turbo Pascal do. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - In D, the loop control variable is not considered a constant. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes?</td> - <td class="yn">partial</td> - <td class="yn">yes</td> - <td class="yn">partial?</td> - </tr> - <tr> - <td colspan="4"> - Neither Parasail nor Rust support goto. However both support break/continue statements - that serve the same purpose in many cases. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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.] - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">no</td> - </tr> - <tr> - <td colspan="4"> - Rust does not support ad-hoc polymorphism. It must be emulated using the trait system. - </td> - </tr> - - <tr> - <td rowspan="2"> - 7B. Recursion. It shall be possible to call functions and procedures recursively. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> -   - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly</td> - <td class="yn">mostly</td> - <td class="yn">mostly?</td> - <td class="yn">mostly</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">partial</td> - <td class="yn">yes</td> - <td class="yn">partial?</td> - <td class="yn">partial?</td> - </tr> - <tr> - <td colspan="4"> - D, Pascal and Rust do not identify in, in-out and out parameters. D, Pascal and Rust can - support in-only parameters. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes?</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes?</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">no</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">no</td> - </tr> - <tr> - <td colspan="4"> - Subscript ranges are not accessible in D or Rust. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">no</td> - <td class="yn">yes</td> - <td class="yn">yes?</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">partial?</td> - <td class="yn">no?</td> - <td class="yn">partial?</td> - <td class="yn">no?</td> - </tr> - <tr> - <td colspan="4"> - D and some Pascal dialects permit access to memory mapped locations. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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). - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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.] - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly</td> - <td class="yn">mostly</td> - <td class="yn">partial</td> - <td class="yn">no</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">partial</td> - </tr> - <tr> - <td colspan="4"> - In Rust, operations to convert between enumerations and strings are not predefined. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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). - </td> - <td class="yn">yes</td> - <td class="yn">mostly</td> - <td class="yn">no</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">no</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">partial?</td> - <td class="yn">yes</td> - <td class="yn">no</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - D supports shared variables and atomic operations, however the idiomatic way of - threading is to rely on immutable data and message passing. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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.] - </td> - <td class="yn">yes?</td> - <td class="yn">yes?</td> - <td class="yn">no</td> - <td class="yn">partial?</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes?</td> - <td class="yn">yes?</td> - </tr> - <tr> - <td colspan="4"> - D provides this in core.time. Parasail provides this in its standard library. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">no?</td> - <td class="yn">no</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">no</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - D synchronized calls allow this. Rust achieves this with std::sync::mpsc. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly?</td> - <td class="yn">mostly?</td> - <td class="yn">no</td> - <td class="yn">mostly?</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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). - </td> - <td class="yn">mostly?</td> - <td class="yn">mostly?</td> - <td class="yn">no</td> - <td class="yn">mostly?</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">partial?</td> - <td class="yn">partial?</td> - <td class="yn">partial</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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).] - </td> - <td class="yn">partial?</td> - <td class="yn">mostly</td> - <td class="yn">partial</td> - <td class="yn">partial?</td> - </tr> - <tr> - <td colspan="4"> - Parasail is constructed to detect all of these mentioned errors, except the out of - memory error, at compile time. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">partial</td> - <td class="yn">partial</td> - <td class="yn">partial</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">no?</td> - <td class="yn">partial</td> - <td class="yn">no</td> - </tr> - <tr> - <td colspan="4"> - Standard Pascal does not specify how to handle errors, whether exceptions or otherwise, - see 10A. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes?</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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.] - </td> - <td class="yn">mostly</td> - <td class="yn">mostly</td> - <td class="yn">no</td> - <td class="yn">mostly</td> - </tr> - <tr> - <td colspan="4"> - None? of these languages permit assertions of frequency. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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.] - </td> - <td class="yn">partial</td> - <td class="yn">no</td> - <td class="yn">no</td> - <td class="yn">no</td> - </tr> - <tr> - <td colspan="4"> - It is possible to statically disallow code from throwing exceptions in D, but that - doesn't fulfil the same function as this requirement. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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). - </td> - <td class="yn">partial?</td> - <td class="yn">no?</td> - <td class="yn">no</td> - <td class="yn">partial</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">partial</td> - <td class="yn">partial?</td> - <td class="yn">no</td> - <td class="yn">partial</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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.] - </td> - <td class="yn">no?</td> - <td class="yn">no?</td> - <td class="yn">no</td> - <td class="yn">no?</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">no</td> - <td class="yn">mostly</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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). - </td> - <td class="yn">partial?</td> - <td class="yn">no?</td> - <td class="yn">partial?</td> - <td class="yn">partial?</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly?</td> - <td class="yn">yes?</td> - <td class="yn">yes?</td> - <td class="yn">yes?</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">partial</td> - <td class="yn">mostly</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly?</td> - <td class="yn">mostly?</td> - <td class="yn">yes</td> - <td class="yn">partial</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">no</td> - <td class="yn">no</td> - <td class="yn">yes</td> - <td class="yn">no</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly?</td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">mostly</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly?</td> - <td class="yn">yes</td> - <td class="yn">yes?</td> - <td class="yn">yes?</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly</td> - <td class="yn">mostly</td> - <td class="yn">mostly</td> - <td class="yn">mostly</td> - </tr> - <tr> - <td colspan="4"> - 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. - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">yes</td> - <td class="yn">yes</td> - <td class="yn">yes?</td> - <td class="yn">yes</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> - - <tr> - <td rowspan="2"> - 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. - </td> - <td class="yn">mostly</td> - <td class="yn">partial</td> - <td class="yn">yes</td> - <td class="yn">partial</td> - </tr> - <tr> - <td colspan="4"> - </td> - </tr> -</table> - - </div> -</div> -{% endblock -%} - - |