diff options
Diffstat (limited to 'project/templates/steelman.html')
| -rw-r--r-- | project/templates/steelman.html | 1409 |
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&do=view&target=parasail_ref_manual.pdf" class="external">Parasail Reference Manual</a>. - Parasail is still a work in progress, and no efforts to standardise it have yet been started.</li> - <li>Pascal: ISO 7185 details Standard Pascal, and is available at several places in various formats. The copy used here - was retrieved from <a href="http://www.pascal-central.com/standards.html" class="external">Pascal Central</a>. - Checking for features of more recent Pascal dialects is done on a more ad hoc basis.</li> + <li>D: The <a href="https://dlang.org/spec/spec.html" class="external">D Language + Specification</a> and the accompanying <a href="https://dlang.org/phobos/index.html" + class="external">Library Reference</a>.</li> + <li>Parasail: The <a href="https://forge.open-do.org/plugins/moinmoin/parasail/FrontPage?action=AttachFile&do=view&target=parasail_ref_manual.pdf" + class="external">Parasail Reference Manual</a>. Parasail is still a work in progress, and no + efforts to standardise it have yet been started.</li> + <li>Pascal: ISO 7185 details Standard Pascal, and is available at several places in various + formats. The copy used here was retrieved from <a href="http://www.pascal-central.com/standards.html" + class="external">Pascal Central</a>. Checking for features of more recent Pascal dialects is + done on a more ad hoc basis.</li> <li>Rust: The closest there is to a definition of the language is given in - <a href="https://doc.rust-lang.org/reference/" class="external">The Rust Reference</a>. It should - be noted that this document is not complete, nor stable. Supplementary information was obtained from - <a href="https://rustbyexample.com/" class="external">Rust by Example</a>. No work to standardise - Rust has been started yet either.</li> + <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: %&'()*+,-./:;<=>? 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: + %&'()*+,-./:;<=>? 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> |