path: root/project/templates/steelman.xhtml

{%- extends "base_plain.xhtml" -%}



{%- block title -%}D, Parasail, Pascal and Rust vs The Steelman{%- endblock -%}



{%- block footer -%}{{ plain_footer ("steelman.xhtml") }}{%- 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 -%}