summaryrefslogtreecommitdiff
path: root/project/templates/steelman.html
diff options
context:
space:
mode:
Diffstat (limited to 'project/templates/steelman.html')
-rw-r--r--project/templates/steelman.html2437
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&amp;do=view&amp;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:
- &#37;&amp;'()*+,-./:;&lt;=&gt;? 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">
- &#160;
- </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 -%}
-
-