summaryrefslogtreecommitdiff
path: root/project/templates/steelman.html
diff options
context:
space:
mode:
Diffstat (limited to 'project/templates/steelman.html')
-rw-r--r--project/templates/steelman.html1409
1 files changed, 760 insertions, 649 deletions
diff --git a/project/templates/steelman.html b/project/templates/steelman.html
index 6fb543b..a62b4ba 100644
--- a/project/templates/steelman.html
+++ b/project/templates/steelman.html
@@ -22,40 +22,47 @@
<h5>Overview</h5>
-<p>From 1975 to 1978 the United States Department of Defense sought to establish a set of requirements for a single
-high level programming language that would also be appropriate for use in Defense embedded systems. After successively
-more refined versions of the requirements from Strawman through to Ironman, this effort culminated in Steelman. The Ada
-programming language, possibly the gold standard language for writing safe and secure software, was designed to comply
-with Steelman.</p>
-
-<p>In 1996 David A. Wheeler <a href="http://www.adahome.com/History/Steelman/steeltab.htm" class="external">wrote a paper</a>
-that compared Ada, C, C++, and Java against the Steelman. This served to highlight the strengths and weaknesses of
-those languages, areas that could be improved, and a scant few requirement points that perhaps aren't even applicable
-anymore. Since then several more programming languages capable of systems work have been created, so it's time for an
-update. More datapoints! Hence, this article will conduct a similar comparison, instead using D, Parasail, Pascal, and Rust.</p>
+<p>From 1975 to 1978 the United States Department of Defense sought to establish a set of
+requirements for a single high level programming language that would also be appropriate for use in
+Defense embedded systems. After successively more refined versions of the requirements from Strawman
+through to Ironman, this effort culminated in Steelman. The Ada programming language, possibly the
+gold standard language for writing safe and secure software, was designed to comply with Steelman.
+</p>
+
+<p>In 1996 David A. Wheeler <a href="http://www.adahome.com/History/Steelman/steeltab.htm"
+class="external">wrote a paper</a> that compared Ada, C, C++, and Java against the Steelman. This
+served to highlight the strengths and weaknesses of those languages, areas that could be improved,
+and a scant few requirement points that perhaps aren't even applicable anymore. Since then several
+more programming languages capable of systems work have been created, so it's time for an update.
+More datapoints! Hence, this article will conduct a similar comparison, instead using D, Parasail,
+Pascal, and Rust.</p>
<h5>The Languages</h5>
-<p><a href="https://dlang.org/" class="external">D</a> was created originally as a reworking of C++ in 2000-2001. It
-serves to represent a progression of the C language family, adding features including contracts, optional garbage
-collection, and a standard threading model.</p>
-
-<p><a href="https://forge.open-do.org/plugins/moinmoin/parasail/" class="external">Parasail</a> is a research language
-created in 2009 by AdaCore, the main vendor of Ada compiler tooling today. The language is designed with implicit
-parallelism throughout, <a href="https://www.embedded.com/design/programming-languages-and-tools/4375616/1/ParaSail--Less-is-more-with-multicore" class="external">simplifying and adding static checking</a>
-to eliminate as many sources of errors as possible. It represents a possible future direction for Ada derived languages.</p>
-
-<p><a href="https://en.wikipedia.org/wiki/Pascal_(programming_language)" class="external">Pascal</a>, like C, predates
-the Steelman requirements and so they cannot have had any influence at all on the language. It was designed for formal
-specification and <a href="https://www.tutorialspoint.com/pascal/pascal_overview.htm" class="external">teaching algorithms</a>.
-Later dialects were used to develop several high profile software projects, including Skype, Photoshop, and
-the original Mac OS. It is useful to consider as a precusor of Ada, sharing many points of functionality and style.</p>
-
-<p><a href="https://www.rust-lang.org/" class="external">Rust</a> is the newest language here, created in 2010. It
-is an odd mix of C and ML influence, placing more emphasis on the functional paradigm than other systems languages.
-Its main claim to fame is adding another method of heap memory safety via
-<a href="https://en.wikipedia.org/wiki/Substructural_type_system" class="external">affine typing</a>.</p>
+<p><a href="https://dlang.org/" class="external">D</a> was created originally as a reworking of C++
+in 2000-2001. It serves to represent a progression of the C language family, adding features
+including contracts, optional garbage collection, and a standard threading model.</p>
+
+<p><a href="https://forge.open-do.org/plugins/moinmoin/parasail/" class="external">Parasail</a> is a
+research language created in 2009 by AdaCore, the main vendor of Ada compiler tooling today. The
+language is designed with implicit parallelism throughout, <a href="https://www.embedded.com/design/programming-languages-and-tools/4375616/1/ParaSail--Less-is-more-with-multicore"
+class="external">simplifying and adding static checking</a> to eliminate as many sources of errors
+as possible. It represents a possible future direction for Ada derived languages.</p>
+
+<p><a href="https://en.wikipedia.org/wiki/Pascal_(programming_language)" class="external">Pascal
+</a>, like C, predates the Steelman requirements and so they cannot have had any influence at all on
+the language. It was designed for formal specification and
+<a href="https://www.tutorialspoint.com/pascal/pascal_overview.htm" class="external">teaching
+algorithms</a>. Later dialects were used to develop several high profile software projects,
+including Skype, Photoshop, and the original Mac OS. It is useful to consider as a precusor of Ada,
+sharing many points of functionality and style.</p>
+
+<p><a href="https://www.rust-lang.org/" class="external">Rust</a> is the newest language here,
+created in 2010. It is an odd mix of C and ML influence, placing more emphasis on the functional
+paradigm than other systems languages. Its main claim to fame is adding another method of heap
+memory safety via <a href="https://en.wikipedia.org/wiki/Substructural_type_system"
+class="external">affine typing</a>.</p>
<table id="lang">
<tr>
@@ -100,43 +107,50 @@ Its main claim to fame is adding another method of heap memory safety via
</tr>
</table>
-<p>* Pascal does not have an official logo, so a picture of <a href="https://en.wikipedia.org/wiki/Blaise_Pascal" class="external">Blaise Pascal</a>,
-in whose honour the language is named, will have to do.</p>
+<p>* Pascal does not have an official logo, so a picture of
+<a href="https://en.wikipedia.org/wiki/Blaise_Pascal" class="external">Blaise Pascal</a>, in whose
+honour the language is named, will have to do.</p>
<h5>Rules for Comparison</h5>
<p>The rule used for this article is that a language provides a feature if:</p>
<ol>
- <li>that feature is defined in the documents widely regarded as the language's defining document(s), <b>or</b></li>
- <li>that feature is widely implemented by compilers typically used for that language with essentially the same semantics.</li>
+ <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>Note the bolded difference from the rules in Wheeler's paper. This is so later dialects of Pascal
+can be considered, rather than strictly adhering to the ISO standard. The other three languages are
+unaffected by this change. Aside from that, effort has been made to keep the evaluation as similar
+as practical to the previous work.</p>
<p>The defining documents used for each of these languages are as follows:</p>
<ul>
- <li>D: The <a href="https://dlang.org/spec/spec.html" class="external">D Language Specification</a> and the
- accompanying <a href="https://dlang.org/phobos/index.html" class="external">Library Reference</a>.</li>
- <li>Parasail: The <a href="https://forge.open-do.org/plugins/moinmoin/parasail/FrontPage?action=AttachFile&amp;do=view&amp;target=parasail_ref_manual.pdf" class="external">Parasail Reference Manual</a>.
- Parasail is still a work in progress, and no efforts to standardise it have yet been started.</li>
- <li>Pascal: ISO 7185 details Standard Pascal, and is available at several places in various formats. The copy used here
- was retrieved from <a href="http://www.pascal-central.com/standards.html" class="external">Pascal Central</a>.
- Checking for features of more recent Pascal dialects is done on a more ad hoc basis.</li>
+ <li>D: The <a href="https://dlang.org/spec/spec.html" class="external">D Language
+ Specification</a> and the accompanying <a href="https://dlang.org/phobos/index.html"
+ class="external">Library Reference</a>.</li>
+ <li>Parasail: The <a href="https://forge.open-do.org/plugins/moinmoin/parasail/FrontPage?action=AttachFile&amp;do=view&amp;target=parasail_ref_manual.pdf"
+ class="external">Parasail Reference Manual</a>. Parasail is still a work in progress, and no
+ efforts to standardise it have yet been started.</li>
+ <li>Pascal: ISO 7185 details Standard Pascal, and is available at several places in various
+ formats. The copy used here was retrieved from <a href="http://www.pascal-central.com/standards.html"
+ class="external">Pascal Central</a>. Checking for features of more recent Pascal dialects is
+ done on a more ad hoc basis.</li>
<li>Rust: The closest there is to a definition of the language is given in
- <a href="https://doc.rust-lang.org/reference/" class="external">The Rust Reference</a>. It should
- be noted that this document is not complete, nor stable. Supplementary information was obtained from
- <a href="https://rustbyexample.com/" class="external">Rust by Example</a>. No work to standardise
- Rust has been started yet either.</li>
+ <a href="https://doc.rust-lang.org/reference/" class="external">The Rust Reference</a>. It
+ should be noted that this document is not complete, nor stable. Supplementary information was
+ obtained from <a href="https://rustbyexample.com/" class="external">Rust by Example</a>. No work
+ to standardise Rust has been started yet either.</li>
</ul>
<h5>Results and Conclusions</h5>
-<p>The appendix lists the Steelman requirements and how well each language supports them. The following table shows a
-summary:</p>
+<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>
@@ -181,47 +195,57 @@ summary:</p>
</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>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>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>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>
+<p>Note that due to the standardisation issues each of these languages has, a (fortunately quite
+low) number of these turned out to be educated guesses. Fairness was the goal, but nonetheless
+reader discretion is advised.</p>
<div class="accordian">
@@ -278,11 +302,12 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ should emphasize program readability (i.e., clarity, understandability, and
+ modifiability of programs). The language should encourage user documentation of
+ programs. It shall require explicit specification of programmer decisions and shall
+ provide defaults only for instances where the default is stated in the language
+ definition, is always meaningful, reflects the most frequent usage in programs, and may
+ be explicitly overridden.
</td>
<td class="yn">partial?</td>
<td class="yn">yes?</td>
@@ -291,23 +316,23 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 1D. Efficiency. The language design should aid the production of efficient object
+ programs. Constructs that have unexpectedly expensive implementations should be easily
+ recognizable by translators and by users. Features should be chosen to have a simple and
+ efficient implementation in many object machines, to avoid execution costs for available
+ generality where it is not needed, to maximize the number of safe optimizations
+ available to translators, and to ensure that unused and constant portions of programs
+ will not add to execution costs. Execution time support packages of the language shall
+ not be included in object code unless they are called.
</td>
<td class="yn">partial?</td>
<td class="yn">yes?</td>
@@ -316,20 +341,20 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</tr>
<tr>
<td colspan="4">
- D incorporates garbage collection to some extent. Parasail is designed to allow as much implicit
- parallelism as possible.
+ 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.
+ consistent semantic structure that minimizes the number of underlying concepts. It
+ should be as small as possible consistent with the needs of the intended applications.
+ It should have few special cases and should be composed from features that are
+ individually simple in their semantics. The language should have uniform syntactic
+ conventions and should not provide several notations for the same concept. No arbitrary
+ restriction should be imposed on a language feature.
</td>
<td class="yn">yes?</td>
<td class="yn">mostly</td>
@@ -344,12 +369,13 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 1F. Implementability. The language shall be composed from features that are understood
+ and can be implemented. The semantics of each feature should be sufficiently well
+ specified and understandable that it will be possible to predict its interaction with
+ other features. To the extent that it does not interfere with other requirements, the
+ language shall facilitate the production of translators that are easy to implement and
+ are efficient during translation. There shall be no language restrictions that are not
+ enforceable by translators.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -364,13 +390,14 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 1G. Machine Independence. The design of the language should strive for machine
+ independence. It shall not dictate the characteristics of object machines or operating
+ systems except to the extent that such characteristics are implied by the semantics of
+ control structures and built-in operations. It shall attempt to avoid features whose
+ semantics depend on characteristics of the object machine or of the object machine
+ operating system. Nevertheless, there shall be a facility for defining those portions of
+ programs that are dependent on the object machine configuration and for conditionally
+ compiling programs depending on the actual configuration.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -384,9 +411,9 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 1H. Complete Definition. The language shall be completely and unambiguously defined. To
+ the extent that a formal definition assists in achieving the above goals (i.e., all of
+ section 1), the language shall be formally defined.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -395,20 +422,22 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ While Pascal is the only one of these languages with an ISO standard, most Pascal
+ programming is done with more recent extended dialects. Rust reference material does not
+ completely describe the language.
</td>
</tr>
<tr>
<td rowspan="2">
- 2A. Character Set. The full set of character graphics that may be used in source programs shall be
- given in the language definition. Every source program shall also have a representation that uses
- only the following 55 character subset of the ASCII graphics: &#37;&amp;'()*+,-./:;&lt;=&gt;? 0123456789
- ABCDEFGHIJKLMNOPQRSTUVWXYZ_ Each additional graphic (i.e., one in the full set but not in the 55
- character set) may be replaced by a sequence of (one or more) characters from the 55 character set
- without altering the semantics of the program. The replacement sequence shall be specified in the
- language definition.
+ 2A. Character Set. The full set of character graphics that may be used in source
+ programs shall be given in the language definition. Every source program shall also have
+ a representation that uses only the following 55 character subset of the ASCII graphics:
+ &#37;&amp;'()*+,-./:;&lt;=&gt;? 0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ_ Each additional
+ graphic (i.e., one in the full set but not in the 55 character set) may be replaced by a
+ sequence of (one or more) characters from the 55 character set without altering the
+ semantics of the program. The replacement sequence shall be specified in the language
+ definition.
</td>
<td class="yn">mostly</td>
<td class="yn">mostly</td>
@@ -422,9 +451,9 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 2B. Grammar. The language should have a simple, uniform, and easily parsed grammar and
+ lexical structure. The language shall have free form syntax and should use familiar
+ notations where such use does not conflict with other goals.
</td>
<td class="yn">partial?</td>
<td class="yn">yes</td>
@@ -433,16 +462,17 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 2C. Syntactic Extensions. The user shall not be able to modify the source language
+ syntax. In particular the user shall not be able to introduce new precedence rules or to
+ define new syntactic forms.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -457,12 +487,13 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 2D. Other Syntactic Issues. Multiple occurrences of a language defined symbol appearing
+ in the same context shall not have essentially different meanings. Lexical units (i.e.,
+ identifiers, reserved words, single and multicharacter symbols, numeric and string
+ literals, and comments) may not cross line boundaries of a source program. All key word
+ forms that contain declarations or statements shall be bracketed (i.e., shall have a
+ closing as well as an opening key word). Programs may not contain unmatched brackets of
+ any kind.
</td>
<td class="yn">mostly</td>
<td class="yn">yes</td>
@@ -471,17 +502,17 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.)
+ 2E. Mnemonic Identifiers. Mnemonically significant identifiers shall be allowed. There
+ shall be a break character for use within identifiers. The language and its translators
+ shall not permit identifiers or reserved words to be abbreviated. (Note that this does
+ not preclude reserved words that are abbreviations of natural language words.)
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -495,10 +526,11 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 2F. Reserved Words. The only reserved words shall be those that introduce special
+ syntactic forms (such as control structures and declarations) or that are otherwise used
+ as delimiters. Words that may be replaced by identifiers, shall not be reserved (e.g.,
+ names of functions, types, constants, and variables shall not be reserved). All reserved
+ words shall be listed in the language definition.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -512,8 +544,8 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 2G. Numeric Literals. There shall be built-in decimal literals. There shall be no
+ implicit truncation or rounding of integer and fixed point literals.
</td>
<td class="yn">mostly</td>
<td class="yn">yes</td>
@@ -522,17 +554,17 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 2H. String Literals. There shall be a built-in facility for fixed length string
+ literals. String literals shall be interpreted as one-dimensional character arrays.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -547,8 +579,8 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 2I. Comments. The language shall permit comments that are introduced by a special (one
+ or two character) symbol and terminated by the next line boundary of the source program.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -563,8 +595,9 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 3A. Strong Typing. The language shall be strongly typed. The type of each variable,
+ array and record component, expression, function, and parameter shall be determinable
+ during translation.
</td>
<td class="yn">mostly</td>
<td class="yn">yes</td>
@@ -573,18 +606,19 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 3B. Type Conversions. The language shall distinguish the concepts of type (specifying
+ data elements with common properties, including operations), subtype (i.e., a subset of
+ the elements of a type, that is characterized by further constraints), and
+ representations (i.e., implementation characteristics). There shall be no implicit
+ conversions between types. Explicit conversion operations shall be automatically defined
+ between types that are characterized by the same logical properties.
</td>
<td class="yn">partial?</td>
<td class="yn">yes</td>
@@ -593,19 +627,20 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 3C. Type Definitions. It shall be possible to define new data types in programs. A type
+ may be defined as an enumeration, an array or record type, an indirect type, an existing
+ type, or a subtype of an existing type. It shall be possible to process type definitions
+ entirely during translation. An identifier may be associated with each type. No
+ restriction shall be imposed on user defined types unless it is imposed on all types.
</td>
<td class="yn">mostly</td>
<td class="yn">yes</td>
@@ -614,17 +649,18 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.]
+ 3D. Subtype Constraints. The constraints that characterize subtypes shall include range,
+ precision, scale, index ranges, and user defined constraints. The value of a subtype
+ constraint for a variable may be specified when the variable is declared. The language
+ should encourage such specifications. [Note that such specifications can aid the
+ clarity, efficiency, maintainability, and provability of programs.]
</td>
<td class="yn">partial</td>
<td class="yn">yes?</td>
@@ -633,16 +669,17 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 3-1A. Numeric Values. The language shall provide distinct numeric types for exact and
+ for approximate computation. Numeric operations and assignment that would cause the most
+ significant digits of numeric values to be truncated (e.g., when overflow occurs) shall
+ constitute an exception situation.
</td>
<td class="yn">partial?</td>
<td class="yn">yes</td>
@@ -651,19 +688,21 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 3-1B. Numeric Operations. There shall be built-in operations (i.e., functions) for
+ conversion between the numeric types. There shall be operations for addition,
+ subtraction, multiplication, division, negation, absolute value, and exponentiation to
+ integer powers for each numeric type. There shall be built-in equality (i.e., equal and
+ unequal) and ordering operations (i.e., less than, greater than, less than or equal, and
+ greater than or equal) between elements of each numeric type. Numeric values shall be
+ equal if and only if they have exactly the same abstract value.
</td>
<td class="yn">mostly</td>
<td class="yn">yes</td>
@@ -672,18 +711,19 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 3-1C. Numeric Variables. The range of each numeric variable must be specified in
+ programs and shall be determined by the time of its allocation. Such specifications
+ shall be interpreted as the minimum range to be implemented and as the maximum range
+ needed by the application. Explicit conversion operations shall not be required between
+ numeric ranges.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -692,18 +732,19 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 3-1D. Precision. The precision (of the mantissa) of each expression result and variable
+ in approximate computations must be specified in programs, and shall be determinable
+ during translation. Precision specifications shall be required for each such variable.
+ Such specifications shall be interpreted as the minimum accuracy (not significance) to
+ be implemented. Approximate results shall be implicitly rounded to the implemented
+ precision. Explicit conversions shall not be required between precisions.
</td>
<td class="yn">mostly</td>
<td class="yn">yes</td>
@@ -712,18 +753,20 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 3-1E. Approximate Arithmetic Implementation. Approximate arithmetic will be implemented
+ using the actual precisions, radix, and exponent range available in the object machine.
+ There shall be built-in operations to access the actual precision, radix, and exponent
+ range of the implementation.
</td>
<td class="yn">yes</td>
<td class="yn">yes?</td>
@@ -732,15 +775,17 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 3-1F. Integer and Fixed Point Numbers. Integer and fixed point numbers shall be treated
+ as exact numeric values. There shall be no implicit truncation or rounding in integer
+ and fixed point computations.
</td>
<td class="yn">mostly</td>
<td class="yn">yes</td>
@@ -749,16 +794,17 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 3-1G. Fixed Point Scale. The scale or step size (i.e., the minimal representable
+ difference between values) of each fixed point variable must be specified in programs
+ and be determinable during translation. Scales shall not be restricted to powers of two.
</td>
<td class="yn">no</td>
<td class="yn">yes</td>
@@ -767,16 +813,17 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</tr>
<tr>
<td colspan="4">
- Of these four languages, inly Parasail supports fixed point types.
+ Of these four languages, only Parasail supports fixed point types.
</td>
</tr>
<tr>
<td rowspan="2">
- 3-1H. Integer and Fixed Point Operations. There shall be integer and fixed point operations for modulo
- and integer division and for conversion between values with different scales. All built-in and predefined
- operations for exact arithmetic shall apply between arbitrary scales. Additional operations between
- arbitrary scales shall be definable within programs.
+ 3-1H. Integer and Fixed Point Operations. There shall be integer and fixed point
+ operations for modulo and integer division and for conversion between values with
+ different scales. All built-in and predefined operations for exact arithmetic shall
+ apply between arbitrary scales. Additional operations between arbitrary scales shall be
+ definable within programs.
</td>
<td class="yn">no</td>
<td class="yn">yes</td>
@@ -791,9 +838,10 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 3-2A. Enumeration Type Definitions. There shall be types that are definable in programs
+ by enumeration of their elements. The elements of an enumeration type may be identifiers
+ or character literals. Each variable of an enumeration type may be restricted to a
+ contiguous subsequence of the enumeration.
</td>
<td class="yn">mostly</td>
<td class="yn">yes</td>
@@ -802,17 +850,18 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 3-2B. Operations on Enumeration Types. Equality, inequality, and the ordering operations
+ shall be automatically defined between elements of each enumeration type. Sufficient
+ additional operations shall be automatically defined so that the successor, predecessor,
+ the position of any element, and the first and last element of the type may be computed.
</td>
<td class="yn">yes</td>
<td class="yn">yes?</td>
@@ -841,8 +890,9 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 3-2D. Character Types. Character sets shall be definable as enumeration types. Character
+ types may contain both printable and control characters. The ASCII character set shall
+ be predefined.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -856,9 +906,10 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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).
+ 3-3A. Composite Type Definitions. It shall be possible to define types that are
+ Cartesian products of other types. Composite types shall include arrays (i.e., composite
+ data with indexable components of homogeneous types) and records (i.e., composite data
+ with labeled components of heterogeneous type).
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -873,10 +924,11 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 3-3B. Component Specifications. For elements of composite types, the type of each
+ component (i.e., field) must be explicitly specified in programs and determinable during
+ translation. Components may be of any type (including array and record types). Range,
+ precision, and scale specifications shall be required for each component of appropriate
+ numeric type.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -885,19 +937,21 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</tr>
<tr>
<td colspan="4">
- Range, precision, and scale specifications are included in numeric type definitions (with support varying,
- see 3-1).
+ 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.
+ 3-3C. Operations on Composite Types. A value accessing operation shall be automatically
+ defined for each component of composite data elements. Assignment shall be automatically
+ defined for components that have alterable values. A constructor operation (i.e., an
+ operation that constructs an element of a type from its constituent parts) shall be
+ automatically defined for each composite type. An assignable component may be used
+ anywhere in a program that a variable of the component's type is permitted. There shall
+ be no automatically defined equivalence operations between values of elements of a
+ composite type.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -911,10 +965,11 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 3-3D. Array Specifications. Arrays that differ in number of dimensions or in component
+ type shall be of different types. The range of subscript values for each dimension must
+ be specified in programs and may be determinable at the time of array allocation. The
+ range of each subscript value must be restricted to a contiguous sequence of integers or
+ to a contiguous sequence from an enumeration type.
</td>
<td class="yn">mostly</td>
<td class="yn">yes</td>
@@ -929,9 +984,10 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 3-3E. Operations on Subarrays. There shall be built-in operations for value access,
+ assignment, and catenation of contiguous sections of one-dimensional arrays of the same
+ component type. The results of such access and catenation operations may be used as
+ actual input parameter.
</td>
<td class="yn">yes</td>
<td class="yn">yes?</td>
@@ -940,16 +996,18 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 3-3F. Nonassignable Record Components. It shall be possible to declare constants and
+ (unary) functions that may be thought of as record components and may be referenced
+ using the same notation as for accessing record components. Assignment shall not be
+ permitted to such components.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -958,14 +1016,16 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</tr>
<tr>
<td colspan="4">
- D classes can include constants and functions. Parasail type inferfaces can include constants and functions.
+ 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.
+ 3-3G. Variants. It shall be possible to define types with alternative record structures
+ (i.e., variants). The structure of each variant shall be determinable during
+ translation.
</td>
<td class="yn">yes</td>
<td class="yn">yes?</td>
@@ -974,16 +1034,16 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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".
+ 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.
+ 3-3H. Tag Fields. Each variant must have a nonassignable tag field (i.e., a component
+ that can be used to discriminate among the variants during execution). It shall not be
+ possible to alter a tag field without replacing the entire variant.
</td>
<td class="yn">yes</td>
<td class="yn">yes?</td>
@@ -997,12 +1057,13 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.]
+ 3-3I. Indirect Types. It shall be possible to define types whose elements are indirectly
+ accessed. Elements of such types may have components of their own type, may have
+ substructure that can be altered during execution, and may be distinct while having
+ identical component values. Such types shall be distinguishable from other composite
+ types in their definitions. An element of an indirect type shall remain allocated as
+ long as it can be referenced by the program. [Note that indirect types require pointers
+ and sometimes heap storage in their implementation.]
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1016,10 +1077,11 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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
+ 3-3J. Operations on Indirect Types. Each execution of the constructor operation for an
+ indirect type shall create a distinct element of the type. An operation that
+ distinguishes between different elements, an operation that replaces all of the
+ component values of an element without altering the element's identity, and an operation
+ that produces a new element having the same component values as its argument, shall be
automatically defined for each indirect type.
</td>
<td class="yn">yes</td>
@@ -1034,8 +1096,9 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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).
+ 3-4A. Bit Strings (i.e., Set Types). It shall be possible to define types whose elements
+ are one-dimensional Boolean arrays represented in maximally packed form (i.e, whose
+ elements are sets).
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1044,18 +1107,19 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 3-4B. Bit String Operations. Set construction, membership (i.e., subscription), set
+ equivalence and nonequivalence, and also complement, intersection, union, and symmetric
+ difference (i.e., component-by-component negation, conjunction, inclusive disjunction,
+ and exclusive disjunction respectively) operations shall be defined automatically for
+ each set type.
</td>
<td class="yn">yes</td>
<td class="yn">yes?</td>
@@ -1069,10 +1133,10 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 3-5A. Encapsulated Definitions. It shall be possible to encapsulate definitions. An
+ encapsulation may contain declarations of anything (including the data elements and
+ operations comprising a type) that is definable in programs. The language shall permit
+ multiple explicit instantiations of an encapsulation.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1087,11 +1151,12 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 3-5B. Effect of Encapsulation. An encapsulation may be used to inhibit external access
+ to implementation properties of the definition. In particular, it shall be possible to
+ prevent external reference to any declaration within the encapsulation including
+ automatically defined operations such as type conversions and equality. Definitions that
+ are made within an encapsulation and are externally accessible may be renamed before use
+ outside the encapsulation.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1105,9 +1170,9 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 3-5C. Own Variables. Variables declared within an encapsulation, but not within a
+ function, procedure, or process of the encapsulation, shall remain allocated and retain
+ their values throughout the scope in which the encapsulation is instantiated.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1121,8 +1186,9 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 4A. Form of Expressions. The parsing of correct expressions shall not depend on the
+ types of their operands or on whether the types of the operands are built into the
+ language.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1136,10 +1202,10 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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).
+ 4B. Type of Expressions. It shall be possible to specify the type of any expression
+ explicitly. The use of such specifications shall be required only where the type of the
+ expression cannot be uniquely determined during translation from the context of its use
+ (as might be the case with a literal).
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1153,13 +1219,14 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.]
+ 4C. Side Effects. The language shall attempt to minimize side effects in expressions,
+ but shall not prohibit all side effects. A side effect shall not be allowed if it would
+ alter the value of a variable that can be accessed at the point of the expression. Side
+ effects shall be limited to own variables of encapsulations. The language shall permit
+ side effects that are necessary to instrument functions and to do storage management
+ within functions. The order of side effects within an expression shall not be
+ guaranteed. [Note that the latter implies that any program that depends on the order of
+ side effects is erroneous.]
</td>
<td class="yn">mostly?</td>
<td class="yn">yes?</td>
@@ -1174,8 +1241,8 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 4D. Allowed Usage. Expressions of a given type shall be allowed wherever both constants
+ and variables of the type are allowed.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1189,10 +1256,10 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 4E. Translation Time Expressions. Expressions that can be evaluated during translation
+ shall be permitted wherever literals of the type are permitted. Translation time
+ expressions that include only literals and the use of translation time facilities (see
+ 11C) shall be evaluated during translation.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1206,9 +1273,10 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 4F. Operator Precedence Levels. The precedence levels (i.e., binding strengths) of all
+ (prefix and infix) operators shall be specified in the language definition, shall not be
+ alterable by the user, shall be few in number, and shall not depend on the types of the
+ operands.
</td>
<td class="yn">mostly</td>
<td class="yn">yes</td>
@@ -1217,19 +1285,20 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.]
+ 4G. Effect of Parentheses. If present, explicit parentheses shall dictate the
+ association of operands with operators. The language shall specify where explicit
+ parentheses are required and shall attempt to minimize the psychological ambiguity in
+ expressions. [Note that this might be accomplished by requiring explicit parentheses to
+ resolve the operator-operand association whenever a nonassociative operator appears to
+ the left of an operator of the same precedence at the least-binding precedence level of
+ any subexpression.]
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1243,9 +1312,10 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 5A. Declarations of Constants. It shall be possible to declare constants of any type.
+ Such constants shall include both those whose values-are determined during translation
+ and those whose value cannot be determined until allocation. Programs may not assign to
+ constants.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1259,10 +1329,11 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.]
+ 5B. Declarations of Variables. Each variable must be declared explicitly. Variables may
+ be of any type. The type of each variable must be specified as part of its declaration
+ and must be determinable during translation. [Note, "variable" throughout this document
+ refers not only to simple variables but also to composite variables and to components of
+ arrays and records.]
</td>
<td class="yn">mostly</td>
<td class="yn">yes</td>
@@ -1271,18 +1342,19 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 5C. Scope of Declarations. Everything (including operators) declared in a program shall
+ have a scope (i.e., a portion of the program in which it can be referenced). Scopes
+ shall be determinable during translation. Scopes may be nested (i.e., lexically
+ embedded). A declaration may be made in any scope. Anything other than a variable shall
+ be accessable within any nested scope of its definition.
</td>
<td class="yn">yes?</td>
<td class="yn">yes</td>
@@ -1296,9 +1368,9 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 5D. Restrictions on Values. Procedures, functions, types, labels, exception situations,
+ and statements shall not be assignable to variables, be computable as values of
+ expressions, or be usable as nongeneric parameters to procedures or functions.
</td>
<td class="yn">no</td>
<td class="yn">no</td>
@@ -1307,7 +1379,8 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</tr>
<tr>
<td colspan="4">
- D and Pascal allow pointers to functions. Parasail allows lambda expressions. Rust has first class functions.
+ D and Pascal allow pointers to functions. Parasail allows lambda expressions. Rust has
+ first class functions.
</td>
</tr>
@@ -1322,9 +1395,10 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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>
@@ -1345,11 +1419,11 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 5G. Scope of Variables. The language shall distinguish between open scopes (i.e., those
+ that are automatically included in the scope of more globally declared variables) and
+ closed scopes (i.e., those in which nonlocal variables must be explicitly Imported).
+ Bodies of functions, procedures, and processes shall be closed scopes. Bodies of
+ classical control structures shall be open scopes.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1363,12 +1437,13 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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).
+ 6A. Basic Control Facility. The (built-in) control mechanisms should be of minimal
+ number and complexity. Each shall provide a single capability and shall have a
+ distinguishing syntax. Nesting of control structures shall be allowed. There shall be no
+ control definition facility. Local scopes shall be allowed within the bodies of control
+ statements. Control structures shall have only one entry point and shall exit to a
+ single point unless exited via an explicit transfer of control (where permitted, see
+ 6G), or the raising of an exception (see 10C).
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1382,10 +1457,10 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 6B. Sequential Control. There shall be a control mechanism for sequencing statements.
+ The language shall not impose arbitrary restrictions on programming style, such as the
+ choice between statement terminators and statement separators, unless the restriction
+ makes programming errors less likely.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1400,13 +1475,14 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 6C. Conditional Control. There shall be conditional control structures that permit
+ selection among alternative control paths. The selected path may depend on the value of
+ a Boolean expression, on a computed choice among labeled alternatives, or on the true
+ condition in a set of conditions. The language shall define the control action for all
+ values of the discriminating condition that are not specified by the program. The user
+ may supply a single control path to be used when no other path is selected. Only the
+ selected branch shall be compiled when the discriminating condition is a translation
+ time expression.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1420,8 +1496,9 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 6D. Short Circuit Evaluation. There shall be infix control operations for short circuit
+ conjunction and disjunction of the controlling Boolean expression in conditional and
+ iterative control structures.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1430,16 +1507,18 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</tr>
<tr>
<td colspan="4">
- Standard Pascal does not provide infix control operations, but both Extended Pascal and Turbo Pascal do.
+ 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.
+ 6E. Iterative Control. There shall be an iterative control structure. The iterative
+ control may be exited (without reentry) at an unrestricted number of places. A
+ succession of values from an enumeration type or the integers may be associated with
+ successive iterations and the value for the current iteration accessed as a constant
+ throughout the loop body.
</td>
<td class="yn">mostly</td>
<td class="yn">yes</td>
@@ -1454,11 +1533,12 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 6G. Explicit Control Transfer. There shall be a mechanism for control transfer (i.e.,
+ the go to). It shall not be possible to transfer out of closed scopes, into narrower
+ scopes, or into control structures. It shall be possible to transfer out of classical
+ control structures. There shall be no control transfer mechanisms in the form of
+ switches, designational expressions, label variables, label parameters, or alter
+ statements.
</td>
<td class="yn">yes?</td>
<td class="yn">partial</td>
@@ -1467,18 +1547,19 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.]
+ 7A. Function and Procedure Definitions. Functions (which return values to expressions)
+ and procedures (which can be called as statements) shall be definable in programs.
+ Functions or procedures that differ in the number or types of their parameters may be
+ denoted by the same identifier or operator (i.e., overloading shall be permitted). [Note
+ that redefinition, as opposed to overloading, of an existing function or procedure is
+ often error prone.]
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1508,9 +1589,9 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 7C. Scope Rules. A reference to an identifier that is not declared in the most local
+ scope shall refer to a program element that is lexically global, rather than to one that
+ is global through the dynamic calling structure.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1524,10 +1605,10 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 7D. Function Declarations. The type of the result for each function must be specified in
+ its declaration and shall be determinable during translation. The results of functions
+ may be of any type. If a result is of a nonindirect array or record type then the number
+ of its components must be determinable by the time of function call.
</td>
<td class="yn">mostly</td>
<td class="yn">mostly</td>
@@ -1541,14 +1622,14 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 7F. Formal Parameter Classes. There shall be three classes of formal data parameters:
+ (a) input parameters, which act as constants that are initialized to the value of
+ corresponding actual parameters at the time of call, (b) input-output parameters, which
+ enable access and assignment to the corresponding actual parameters, either throughout
+ execution or only upon call and prior to any exit, and (c) output parameters, whose
+ values are transferred to the corresponding actual parameter only at the time of normal
+ exit. In the latter two cases the corresponding actual parameter shall be determined at
+ time of call and must be a variable or an assignable component of a composite type.
</td>
<td class="yn">partial</td>
<td class="yn">yes</td>
@@ -1557,18 +1638,19 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 7G. Parameter Specifications. The type of each formal parameter must be explicitly
+ specified in programs and shall be determinable during translation. Parameters may be of
+ any type. The language shall not require user specification of subtype constraints for
+ formal parameters. If such constraints are permitted they shall be interpreted as
+ assertions and not as additional overloading. Corresponding formal and actual parameters
+ must be of the same type.
</td>
<td class="yn">yes?</td>
<td class="yn">yes</td>
@@ -1582,11 +1664,11 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 7H. Formal Array Parameters. The number of dimensions for formal array parameters must
+ be specified in programs and shall be determinable during translation. Determination of
+ the subscript range for formal array parameters may be delayed until invocation and may
+ vary from call to call. Subscript ranges shall be accessible within function and
+ procedure bodies without being passed as explicit parameters.
</td>
<td class="yn">no</td>
<td class="yn">yes</td>
@@ -1601,13 +1683,14 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 7I. Restrictions to Prevent Aliasing. The language shall attempt to prevent aliasing
+ (i.e., multiple access paths to the same variable or record component) that is not
+ intended, but shall not prohibit all aliasing. Aliasing shall not be permitted between
+ output parameters nor between an input-output parameter and a nonlocal variable.
+ Unintended aliasing shall not be permitted between input-output parameters. A
+ restriction limiting actual input-output parameters to variables that are nowhere
+ referenced as nonlocals within a function or routine, is not prohibited. All aliasing of
+ components of elements of an indirect type shall be considered intentional.
</td>
<td class="yn">no</td>
<td class="yn">yes</td>
@@ -1621,9 +1704,10 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 8A. Low Level Input-Output. There shall be a few low level input-output operations that
+ send and receive control information to and from physical channels and devices. The low
+ level operations shall be chosen to insure that all user level input-output operations
+ can be defined within the language.
</td>
<td class="yn">partial?</td>
<td class="yn">no?</td>
@@ -1638,10 +1722,11 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 8B. User Level Input-Output. The language shall specify (i.e., give calling format and
+ general semantics) a recommended set of user level input-output operations. These shall
+ include operations to create, delete, open, close, read, write, position, and
+ interrogate both sequential and random access files and to alter the association between
+ logical files and physical devices.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1655,9 +1740,10 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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).
+ 8C. Input Restrictions. User level input shall be restricted to data whose record
+ representations are known to the translator (i.e., data that is created and written
+ entirely within the program or data whose representation is explicitly specified in the
+ program).
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1671,9 +1757,9 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.]
+ 8D. Operating System Independence. The language shall not require the presence of an
+ operating system. [Note that on many machines it will be necessary to provide run-time
+ procedures to implement some features of the language.]
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1687,9 +1773,9 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 8E. Resource Control. There shall be a few low level operations to interrogate and
+ control physical resources (e.g., memory or processors) that are managed (e.g.,
+ allocated or scheduled) by built-in features of the language.
</td>
<td class="yn">mostly</td>
<td class="yn">mostly</td>
@@ -1698,18 +1784,19 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 8F. Formating. There shall be predefined operations to convert between the symbolic and
+ internal representation of all types that have literal forms in the language (e.g.,
+ strings of digits to integers, or an enumeration element to its symbolic form). These
+ conversion operations shall have the same semantics as those specified for literals in
+ programs.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1724,10 +1811,11 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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).
+ 9A. Parallel Processing. It shall be possible to define parallel processes. Processes
+ (i.e., activation instances of such a definition) may be initiated at any point within
+ the scope of the definition. Each process (activation) must have a name. It shall not be
+ possible to exit the scope of a process name unless the process is terminated (or
+ uninitiated).
</td>
<td class="yn">yes</td>
<td class="yn">mostly</td>
@@ -1736,18 +1824,20 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 9B. Parallel Process Implementation. The parallel processing facility shall be designed
+ to minimize execution time and space. Processes shall have consistent semantics whether
+ implemented on multicomputers, multiprocessors, or with interleaved execution on a
+ single processor.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1761,10 +1851,11 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 9C. Shared Variables and Mutual Exclusion. It shall be.possible to mark variables that
+ are shared among parallel processes. An unmarked variable that is assigned on one path
+ and used on another shall cause a warning. It shall be possible efficiently to perform
+ mutual exclusion in programs. The language shall not require any use of mutual
+ exclusion.
</td>
<td class="yn">partial?</td>
<td class="yn">yes</td>
@@ -1773,20 +1864,21 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.]
+ 9D. Scheduling. The semantics of the built-in scheduling algorithm shall be
+ first-in-first-out within priorities. A process may alter its own priority. If the
+ language provides a default priority for new processes it shall be the priority of its
+ initiating process. The built-in scheduling algorithm shall not require that
+ simultaneously executed processes on different processors have the same priority. [Note
+ that this rule gives maximum scheduling control to the user without loss of efficiency.
+ Note also that priority specification does not impose a specific execution order among
+ parallel paths and thus does not provide a means for mutual exclusion.]
</td>
<td class="yn">yes?</td>
<td class="yn">yes?</td>
@@ -1800,11 +1892,11 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 9E. Real Time. It shall be possible to access a real time clock. There shall be
+ translation time constants to convert between the implementation units and the program
+ units for real time. On any control path, it shall be possible to delay until at least a
+ specified time before continuing execution. A process may have an accessible clock
+ giving the cumulative processing time (i.e., CPU time) for that process.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1819,8 +1911,9 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 9G. Asynchronous Termination. It shall be possible to terminate another process. The
+ terminated process may designate the sequence of statements it will execute in response
+ to the induced termination.
</td>
<td class="yn">yes</td>
<td class="yn">no?</td>
@@ -1829,17 +1922,18 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 9H. Passing Data. It shall be possible to pass data between processes that do not share
+ variables. It shall be possible to delay such data transfers until both the sending and
+ receiving processes have requested the transfer.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -1854,9 +1948,9 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 9I. Signalling. It shall be possible to set a signal (without waiting), and to wait for
+ a signal (without delay, if it is already set). Setting a signal, that is not already
+ set, shall cause exactly one waiting path to continue.
</td>
<td class="yn">mostly?</td>
<td class="yn">mostly?</td>
@@ -1870,8 +1964,9 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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).
+ 9J. Waiting. It shall be possible to wait for, determine, and act upon the first
+ completed of several wait operations (including those used for data passing, signalling,
+ and real time).
</td>
<td class="yn">mostly?</td>
<td class="yn">mostly?</td>
@@ -1885,12 +1980,12 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 10A. Exception Handling Facility. There shall be an exception handling mechanism for
+ responding to unplanned error situations detected in declarations and statements during
+ execution. The exception situations shall include errors detected by hardware, software
+ errors detected during execution, error situations in built-in operations, and user
+ defined exceptions. Exception identifiers shall have a scope. Exceptions should add to
+ the execution time of programs only if they are raised.
</td>
<td class="yn">yes</td>
<td class="yn">partial?</td>
@@ -1899,22 +1994,24 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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).]
+ 10B. Error Situations. The errors detectable during execution shall include exceeding
+ the specified range of an array subscript, exceeding the specified range of a variable,
+ exceeding the implemented range of a variable, attempting to access an uninitialized
+ variable, attempting to access a field of a variant that is not present, requesting a
+ resource (such as stack or heap storage) when an insufficient quantity remains, and
+ failing to satisfy a program specified assertion. [Note that some are very expensive to
+ detect unless aided by special hardware, and consequently their detection will often be
+ suppressed (see 10G).]
</td>
<td class="yn">partial?</td>
<td class="yn">mostly</td>
@@ -1923,20 +2020,21 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</tr>
<tr>
<td colspan="4">
- Parasail is constructed to detect all of these mentioned errors, except the out of memory error, at
- compile time.
+ 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.
+ 10C. Raising Exceptions. There shall be an operation that raises an exception. Raising
+ an exception shall cause transfer of control to the most local enclosing exception
+ handler for that exception without completing execution of the current statement or
+ declaration, but shall not of itself cause transfer out of a function, procedure, or
+ process. Exceptions that are not handled within a function or procedure shall be raised
+ again at the point of call in their callers. Exceptions that are not handled within a
+ process shall terminate the process. Exceptions that can be raised by built-in
+ operations shall be given in the language definition.
</td>
<td class="yn">yes</td>
<td class="yn">partial</td>
@@ -1945,20 +2043,22 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ exceptions that can occur in a specified statement sequence. The user may supply a
+ single control path for all exceptions not otherwise mentioned in such a discrimination.
+ It shall be possible to raise the exception that selected the current handler when
+ exiting the handler.
</td>
<td class="yn">yes</td>
<td class="yn">no?</td>
@@ -1967,14 +2067,15 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</tr>
<tr>
<td colspan="4">
- Standard Pascal does not specify how to handle errors, whether exceptions or otherwise, see 10A.
+ 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.
+ 10E. Order of Exceptions. The order in which exceptions in different parts of an
+ expression are detected shall not be guaranteed by the language or by the translator.
</td>
<td class="yn">yes?</td>
<td class="yn">yes</td>
@@ -1988,10 +2089,11 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.]
+ 10F. Assertions. It shall be possible to include assertions in programs. If an assertion
+ is false when encountered during execution, it shall raise an exception. It shall also
+ be possible to include assertions, such as the expected frequency for selection of a
+ conditional path, that cannot be verified. [Note that assertions can be used to aid
+ optimization and maintenance.]
</td>
<td class="yn">mostly</td>
<td class="yn">mostly</td>
@@ -2006,10 +2108,11 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.]
+ 10G. Suppressing Exceptions. It shall be possible during translation to suppress
+ individually the execution time detection of exceptions within a given scope. The
+ language shall not guarantee the integrity of the values produced when a suppressed
+ exception occurs. [Note that suppression of an exception is not an assertion that the
+ corresponding error will not occur.]
</td>
<td class="yn">partial</td>
<td class="yn">no</td>
@@ -2018,24 +2121,24 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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).
+ 11A. Data Representation. The language shall permit but not require programs to specify
+ a single physical representation for the elements of a type. These specifications shall
+ be separate from the logical descriptions. Physical representation shall include object
+ representation of enumeration elements, order of fields, width of fields, presence of
+ "don't care" fields, positions of word boundaries, and object machine addresses. In
+ particular, the facility shall be sufficient to specify the physical representation of
+ any record whose format is determined by considerations that are entirely external to
+ the program, translator, and language. The language and its translators shall not
+ guarantee any particular choice for those aspects of physical representation that are
+ unspecified by the program. It shall be possible to specify the association of physical
+ resources (e.g., interrupts) to program elements (e.g., exceptions or signals).
</td>
<td class="yn">partial?</td>
<td class="yn">no?</td>
@@ -2049,13 +2152,13 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 11C. Translation Time Facilities. To aid conditional compilation, it shall be possible
+ to interrogate properties that are known during translation including characteristics of
+ the object configuration, of function and procedure calling environments, and of actual
+ parameters. For example, it shall be possible to determine whether the caller has
+ suppressed a given exception, the callers optimization criteria, whether an actual
+ parameter is a translation time expression, the type of actual generic parameters, and
+ the values of constraints characterizing the subtype of actual parameters.
</td>
<td class="yn">partial</td>
<td class="yn">partial?</td>
@@ -2069,13 +2172,14 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.]
+ 11D. Object System Configuration. The object system configuration must be explicitly
+ specified in each separately translated unit. Such specifications must include the
+ object machine model, the operating system if present, peripheral equipment, and the
+ device configuration, and may include special hardware options and memory size. The
+ translator will use such specifications when generating object code. [Note that programs
+ that depend on the specific characteristics of the object machine, may be made more
+ portable by enclosing those portions in branches of conditionals on the object machine
+ configuration.]
</td>
<td class="yn">no?</td>
<td class="yn">no?</td>
@@ -2089,10 +2193,10 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 11E. Interface to Other Languages. There shall be a machine independent interface to
+ other programming languages including assembly languages. Any program element that is
+ referenced in both the source language program and foreign code must be identified in
+ the interface. The source language of the foreign code must also be identified.
</td>
<td class="yn">yes</td>
<td class="yn">no</td>
@@ -2101,22 +2205,23 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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).
+ 11F. Optimization. Programs may advise translators on the optimization criteria to be
+ used in a scope. It shall be possible in programs to specify whether minimum translation
+ costs or minimum execution costs are more important, and whether execution time or
+ memory space is to be given preference. All such specifications shall be optional.
+ Except for the amount of time and space required during execution, approximate values
+ beyond the specified precision, the order in which exceptions are detected, and the
+ occurrence of side effects within an expression, optimization shall not alter the
+ semantics of correct programs, (e.g., the semantics of parameters will be unaffected by
+ the choice between open and closed calls).
</td>
<td class="yn">partial?</td>
<td class="yn">no?</td>
@@ -2130,12 +2235,12 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 12A. Library. There shall be an easily accessible library of generic definitions and
+ separately translated units. All predefined definitions shall be in the library. Library
+ entries may include those used as input-output packages, common pools of shared
+ declarations, application oriented software packages, encapsulations, and machine
+ configuration specifications. The library shall be structured to allow entries to be
+ associated with particular applications, projects, and users.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -2149,10 +2254,11 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 12B. Separately Translated Units. Separately translated units may be assembled into
+ operational systems. It shall be possible for a separately translated unit to reference
+ exported definitions of other units. All language imposed restrictions shall be enforced
+ across such interfaces. Separate translation shall not change the semantics of a correct
+ program.
</td>
<td class="yn">mostly?</td>
<td class="yn">yes?</td>
@@ -2166,11 +2272,11 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 12D. Generic Definitions. Functions, procedures, types, and encapsulations may have
+ generic parameters. Generic parameters shall be instantiated during translation and
+ shall be interpreted in the context of the instantiation. An actual generic parameter
+ may be any defined identifier (including those for variables, functions, procedures,
+ processes, and types) or the value of any expression.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -2179,18 +2285,19 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 13A. Defining Documents. The language shall have a complete and unambiguous defining
+ document. It should be possible to predict the possible actions of any syntactically
+ correct program from the language definition. The language documentation shall include
+ the syntax, semantics, and appropriate examples of each built-in and predefined feature.
+ A recommended set of translation diagnostic and warning messages shall be included in
+ the language definition.
</td>
<td class="yn">mostly?</td>
<td class="yn">mostly?</td>
@@ -2205,7 +2312,8 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ established for standards control and for certification that translators meet the
+ standard.
</td>
<td class="yn">no</td>
<td class="yn">no</td>
@@ -2219,10 +2327,10 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 13C. Completeness of Implementations. Translators shall implement the standard
+ definition. Every translator shall be able to process any syntactically correct program.
+ Every feature that is available to the user shall be defined in the standard, in an
+ accessible library, or in the source program.
</td>
<td class="yn">mostly?</td>
<td class="yn">yes</td>
@@ -2236,15 +2344,16 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 13D. Translator Diagnostics. Translators shall be responsible for reporting errors that
+ are detectable during translation and for optimizing object code. Translators shall be
+ responsible for the integrity of object code in affected translation units when any
+ separately translated unit is modified, and shall ensure that shared definitions have
+ compatible representations in all translation units. Translators shall do full syntax
+ and type checking, shall check that all language imposed restrictions are met, and
+ should provide warnings where constructs will be dangerous or unusually expensive in
+ execution and shall attempt to detect exceptions during translation. If the translator
+ determines that a call on a routine will not terminate normally, the exception shall be
+ reported as a translation error at the point of call.
</td>
<td class="yn">mostly?</td>
<td class="yn">yes</td>
@@ -2258,12 +2367,12 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ 13E. Translator Characteristics. Translators for the language will be written in the
+ language and will be able to produce code for a variety of object machines. The machine
+ independent parts of translators should be separate from code generators. Although it is
+ desirable, translators need not be able to execute on every object machine. The internal
+ characteristics of the translator (i.e., the translation method) shall not be specified
+ by the language definition or standards.
</td>
<td class="yn">mostly</td>
<td class="yn">mostly</td>
@@ -2272,20 +2381,21 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
</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.
+ 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.
+ 13F. Restrictions on Translators. Translators shall fail to translate otherwise correct
+ programs only when the program requires more resources during translation than are
+ available on the host machine or when the program calls for resources that are
+ unavailable in the specified object system configuration. Neither the language nor its
+ translators shall impose arbitrary restrictions on language features. For example, they
+ shall not impose restrictions on the number of array dimensions, on the number of
+ identifiers, on the length of identifiers, or on the number of nested parentheses
+ levels.
</td>
<td class="yn">yes</td>
<td class="yn">yes</td>
@@ -2300,13 +2410,14 @@ turned out to be educated guesses. Fairness was the goal, but nonetheless reader
<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.
+ conjunction with a variety of useful software tools and application support packages.
+ These will be developed as early as possible and will include editors, interpreters,
+ diagnostic aids, program analyzers, documentation aids, testing aids, software
+ maintenance tools, optimizers, and application libraries. There will be a consistent
+ user interface for these tools. Where practical software tools and aids will be written
+ in the language. Support for the design, implementation, distribution, and maintenance
+ of translators, software tools and aids, and application libraries will be provided
+ independently of the individual projects that use them.
</td>
<td class="yn">mostly</td>
<td class="yn">partial</td>