Article for D, Parasail, Pascal, and Rust vs The Steelman added

8 files changed, 2382 insertions, 0 deletions

diff --git a/project/assets/css/steelman.css b/project/assets/css/steelman.css
new file mode 100644
index 0000000..4123e75
--- /dev/null
+++ b/project/assets/css/steelman.css
@@ -0,0 +1,60 @@
+
+
+table {
+    margin: 2em auto 2em auto;
+    max-width: 60em;
+}
+
+
+
+
+table#lang {
+    min-width: 30em;
+}
+
+
+table#lang, table#lang td {
+    border: none;
+}
+
+
+
+
+table#results, table#results th, table#results td {
+    border: 1px solid gray;
+    font: 0.9em/1.1em sans-serif;
+}
+
+
+table#results td {
+    text-align: center;
+}
+
+
+
+
+table#appendix, table#appendix th, table#appendix td {
+    border: 1px solid gray;
+    font: 0.9em/1.1em sans-serif;
+}
+
+
+table#appendix td {
+    padding: 0.5em 0.2em 0.5em 0.2em;
+}
+
+
+table#appendix td#yn {
+    text-align: center;
+    height: 1em;
+}
+
+
+
+
+table#results th, table#appendix th {
+    font-weight: bold;
+    text-align: center;
+    padding: 0.5em 0.5em 0.5em 0.5em;
+}
+
diff --git a/project/assets/img/logo_d_small.png b/project/assets/img/logo_d_small.png
new file mode 100644
index 0000000..c0ed68a
--- /dev/null
+++ b/project/assets/img/logo_d_small.png
diff --git a/project/assets/img/logo_parasail_small.png b/project/assets/img/logo_parasail_small.png
new file mode 100644
index 0000000..baa9da6
--- /dev/null
+++ b/project/assets/img/logo_parasail_small.png
diff --git a/project/assets/img/logo_pascal_small.png b/project/assets/img/logo_pascal_small.png
new file mode 100644
index 0000000..19430c1
--- /dev/null
+++ b/project/assets/img/logo_pascal_small.png
diff --git a/project/assets/img/logo_rust_small.png b/project/assets/img/logo_rust_small.png
new file mode 100644
index 0000000..aba6e75
--- /dev/null
+++ b/project/assets/img/logo_rust_small.png
diff --git a/project/complexity.yml b/project/complexity.yml
index ee8bc36..ef1bccc 100644
--- a/project/complexity.yml
+++ b/project/complexity.yml
@@ -19,4 +19,5 @@ unexpanded_templates:
  - "sunset.html"
  - "sokoban.html"
  - "links.html"
+ - "steelman.html"
 
diff --git a/project/templates/index.html b/project/templates/index.html
index 7180af6..df1de33 100644
--- a/project/templates/index.html
+++ b/project/templates/index.html
@@ -16,6 +16,9 @@
 {% block content %}
 
 <ul class="index">
+    <li><a href="/steelman.html">D, Parasail, Pascal, and Rust vs The Steelman</a><br>
+        <span class="post">(Posted 29/10/2017)</span></li>
+
     <li><a href="/sokoban.html">Sokoban Clone</a><br>
         <span class="post">(Posted 8/8/2017)</span></li>
 
diff --git a/project/templates/steelman.html b/project/templates/steelman.html
new file mode 100644
index 0000000..175076f
--- /dev/null
+++ b/project/templates/steelman.html
@@ -0,0 +1,2318 @@
+
+{% extends "base.html" %}
+
+
+
+{% block title %}D, Parasail, Pascal and Rust vs The Steelman{% endblock %}
+
+
+
+{% block style %}
+    <link href="/css/steelman.css" rel="stylesheet">
+{% endblock %}
+
+
+
+{% block content %}
+
+<h4>D, Parasail, Pascal, and Rust vs The Steelman</h4>
+
+<h5>29/10/2017</h5>
+
+
+<h5>Overview</h5>
+
+<p>From 1975 to 1978 the United States Department of Defense sought to establish a set of requirements for a single
+high level programming language that would also be appropriate for use in Defense embedded systems. After successively
+more refined versions of the requirements from Strawman through to Ironman, this effort culminated in Steelman. The Ada
+programming language, possibly the gold standard language for writing safe and secure software, was designed to comply
+with Steelman.</p>
+
+<p>In 1996 David A. Wheeler <a href="http://www.adahome.com/History/Steelman/steeltab.htm" target="_blank">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/" target="_blank">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/" target="_blank">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-multicoreIt provides an example of a possible" target="_blank">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)" target="_blank">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" target="_blank">teaching algorithms</a>.
+Later dialects were used to develop several high profile software projects, including Skype, Photoshop, and parts of
+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/" target="_blank">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" target="_blank">affine typing</a>.</p>
+
+<table id="lang">
+    <tr>
+        <td>
+            <figure>
+                <img src="/img/logo_d_small.png"
+                     alt="Logo for the D programming language"
+                     height="124"
+                     width="164">
+                <figcaption>D</figcaption>
+            </figure>
+        </td>
+        <td>
+            <figure>
+                <img src="/img/logo_parasail_small.png"
+                     alt="Logo for the Parasail programming language"
+                     height="144"
+                     width="149">
+                <figcaption>Parasail</figcaption>
+            </figure>
+        </td>
+    </tr>
+    <tr>
+        <td>
+            <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">
+                <figcaption>Pascal*</figcaption>
+            </figure>
+        </td>
+        <td>
+            <figure>
+                <img src="/img/logo_rust_small.png"
+                     alt="Logo for the Rust programming language"
+                     height="144"
+                     width="144">
+                <figcaption>Rust</figcaption>
+            </figure>
+        </td>
+    </tr>
+</table>
+
+<p>* Pascal does not have an official logo, so a picture of <a href="https://en.wikipedia.org/wiki/Blaise_Pascal" target="_blank">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" target="_blank">D Language Specification</a> and the
+        accompanying <a href="https://dlang.org/phobos/index.html" target="_blank">Library Reference</a>.</li>
+    <li>Parasail: The <a href="https://forge.open-do.org/plugins/moinmoin/parasail/FrontPage?action=AttachFile&do=view&target=parasail_ref_manual.pdf" target="_blank">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" target="_blank">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/" target="_blank">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/" target="_blank">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>
+
+<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 id="yn">yes</td>
+        <td id="yn">no?</td>
+        <td id="yn">yes?</td>
+        <td id="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 id="yn">yes?</td>
+        <td id="yn">yes</td>
+        <td id="yn">partial?</td>
+        <td id="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 id="yn">partial?</td>
+        <td id="yn">yes?</td>
+        <td id="yn">mostly?</td>
+        <td id="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 id="yn">partial?</td>
+        <td id="yn">yes?</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes?</td>
+        <td id="yn">mostly</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">mostly?</td>
+        <td id="yn">mostly?</td>
+    </tr>
+    <tr>
+        <td colspan="4">
+            While Pascal is the only one of these languages with an ISO standard, most Pascal programming is done
+            with more recent extended dialects. Rust reference material does not completely describe the language.
+        </td>
+    </tr>
+
+    <tr>
+        <td rowspan="2">
+            2A. Character Set. The full set of character graphics that may be used in source programs shall be
+            given in the language definition. Every source program shall also have a representation that uses
+            only the following 55 character subset of the ASCII graphics: %&'()*+,-./:;<=>? 0123456789
+            ABCDEFGHIJKLMNOPQRSTUVWXYZ_ Each additional graphic (i.e., one in the full set but not in the 55
+            character set) may be replaced by a sequence of (one or more) characters from the 55 character set
+            without altering the semantics of the program. The replacement sequence shall be specified in the
+            language definition.
+        </td>
+        <td id="yn">mostly</td>
+        <td id="yn">mostly</td>
+        <td id="yn">mostly</td>
+        <td id="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 id="yn">partial?</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">mostly</td>
+        <td id="yn">yes</td>
+        <td id="yn">mostly</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">mostly</td>
+        <td id="yn">yes</td>
+        <td id="yn">mostly?</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">partial</td>
+        <td id="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 id="yn">mostly</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">partial?</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes?</td>
+        <td id="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 id="yn">mostly</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes?</td>
+        <td id="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 id="yn">partial</td>
+        <td id="yn">yes?</td>
+        <td id="yn">mostly?</td>
+        <td id="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 id="yn">partial?</td>
+        <td id="yn">yes</td>
+        <td id="yn">partial?</td>
+        <td id="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 id="yn">mostly</td>
+        <td id="yn">yes</td>
+        <td id="yn">mostly</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">mostly</td>
+        <td id="yn">yes</td>
+        <td id="yn">no</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes?</td>
+        <td id="yn">partial</td>
+        <td id="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 id="yn">mostly</td>
+        <td id="yn">yes</td>
+        <td id="yn">partial</td>
+        <td id="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 id="yn">no</td>
+        <td id="yn">yes</td>
+        <td id="yn">no</td>
+        <td id="yn">no</td>
+    </tr>
+    <tr>
+        <td colspan="4">
+            Of these four languages, inly 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 id="yn">no</td>
+        <td id="yn">yes</td>
+        <td id="yn">no</td>
+        <td id="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 id="yn">mostly</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes?</td>
+        <td id="yn">yes?</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">mostly</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes?</td>
+        <td id="yn">no</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">no?</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes?</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes?</td>
+        <td id="yn">yes?</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes?</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">mostly?</td>
+        <td id="yn">yes?</td>
+        <td id="yn">mostly?</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">mostly</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">mostly</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes?</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">no</td>
+        <td id="yn">no</td>
+        <td id="yn">no?</td>
+        <td id="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 id="yn">partial</td>
+        <td id="yn">partial</td>
+        <td id="yn">partial?</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">partial</td>
+        <td id="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 id="yn">mostly</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes?</td>
+        <td id="yn">partial</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+    </tr>
+    <tr>
+        <td colspan="4">
+            &nbsp;
+        </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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">mostly</td>
+        <td id="yn">mostly</td>
+        <td id="yn">mostly?</td>
+        <td id="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 id="yn">partial</td>
+        <td id="yn">yes</td>
+        <td id="yn">partial?</td>
+        <td id="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 id="yn">yes?</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">no</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 (l.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 id="yn">no</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes?</td>
+        <td id="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 id="yn">partial?</td>
+        <td id="yn">no?</td>
+        <td id="yn">partial?</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">mostly</td>
+        <td id="yn">mostly</td>
+        <td id="yn">partial</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">mostly</td>
+        <td id="yn">no</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">no</td>
+        <td id="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 id="yn">partial?</td>
+        <td id="yn">yes</td>
+        <td id="yn">no</td>
+        <td id="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 id="yn">yes?</td>
+        <td id="yn">yes?</td>
+        <td id="yn">no</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes?</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">no?</td>
+        <td id="yn">no</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">no</td>
+        <td id="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 id="yn">mostly?</td>
+        <td id="yn">mostly?</td>
+        <td id="yn">no</td>
+        <td id="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 id="yn">mostly?</td>
+        <td id="yn">mostly?</td>
+        <td id="yn">no</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">partial?</td>
+        <td id="yn">partial?</td>
+        <td id="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 id="yn">partial?</td>
+        <td id="yn">mostly</td>
+        <td id="yn">partial</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">partial</td>
+        <td id="yn">partial</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">no?</td>
+        <td id="yn">partial</td>
+        <td id="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 id="yn">yes?</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">mostly</td>
+        <td id="yn">mostly</td>
+        <td id="yn">no</td>
+        <td id="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 id="yn">partial</td>
+        <td id="yn">no</td>
+        <td id="yn">no</td>
+        <td id="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 id="yn">partial?</td>
+        <td id="yn">no?</td>
+        <td id="yn">no</td>
+        <td id="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 id="yn">partial</td>
+        <td id="yn">partial?</td>
+        <td id="yn">no</td>
+        <td id="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 id="yn">no?</td>
+        <td id="yn">no?</td>
+        <td id="yn">no</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">no</td>
+        <td id="yn">mostly</td>
+        <td id="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 id="yn">partial?</td>
+        <td id="yn">no?</td>
+        <td id="yn">partial?</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">mostly?</td>
+        <td id="yn">yes?</td>
+        <td id="yn">yes?</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">partial</td>
+        <td id="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 id="yn">mostly?</td>
+        <td id="yn">mostly?</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">no</td>
+        <td id="yn">no</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">mostly?</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="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 id="yn">mostly?</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes?</td>
+        <td id="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 id="yn">mostly</td>
+        <td id="yn">mostly</td>
+        <td id="yn">mostly</td>
+        <td id="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 id="yn">yes</td>
+        <td id="yn">yes</td>
+        <td id="yn">yes?</td>
+        <td id="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 id="yn">mostly</td>
+        <td id="yn">partial</td>
+        <td id="yn">yes</td>
+        <td id="yn">partial</td>
+    </tr>
+    <tr>
+        <td colspan="4">
+        </td>
+    </tr>
+</table>
+
+{% endblock %}
+
+