summaryrefslogtreecommitdiff
path: root/project/templates/steelman.html
blob: bb61548868950fa85cc09981271171030dd3e05b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327

{% extends "base.html" %}



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



{% block style %}
    <link href="/css/steelman.css" rel="stylesheet">
{% endblock %}



{% block content %}

<h4>D, Parasail, Pascal, and Rust vs The Steelman</h4>

<h5>29/10/2017</h5>


<h5>Overview</h5>

<p>From 1975 to 1978 the United States Department of Defense sought to establish a set of requirements for a single
high level programming language that would also be appropriate for use in Defense embedded systems. After successively
more refined versions of the requirements from Strawman through to Ironman, this effort culminated in Steelman. The Ada
programming language, possibly the gold standard language for writing safe and secure software, was designed to comply
with Steelman.</p>

<p>In 1996 David A. Wheeler <a href="http://www.adahome.com/History/Steelman/steeltab.htm" target="_blank">wrote a paper</a>
that compared Ada, C, C++, and Java against the Steelman. This served to highlight the strengths and weaknesses of
those languages, areas that could be improved, and a scant few requirement points that perhaps aren't even applicable
anymore. Since then several more programming languages capable of systems work have been created, so it's time for an
update. More datapoints! Hence, this article will conduct a similar comparison, instead using D, Parasail, Pascal, and Rust.</p>


<h5>The Languages</h5>

<p><a href="https://dlang.org/" target="_blank">D</a> was created originally as a reworking of C++ in 2000-2001. It
serves to represent a progression of the C language family, adding features including contracts, optional garbage
collection, and a standard threading model.</p>

<p><a href="https://forge.open-do.org/plugins/moinmoin/parasail/" target="_blank">Parasail</a> is a research language
created in 2009 by AdaCore, the main vendor of Ada compiler tooling today. The language is designed with implicit
parallelism throughout, <a href="https://www.embedded.com/design/programming-languages-and-tools/4375616/1/ParaSail--Less-is-more-with-multicore" target="_blank">simplifying and adding static checking</a>
to eliminate as many sources of errors as possible. It represents a possible future direction for Ada derived languages.</p>

<p><a href="https://en.wikipedia.org/wiki/Pascal_(programming_language)" target="_blank">Pascal</a>, like C, predates
the Steelman requirements and so they cannot have had any influence at all on the language. It was designed for formal
specification and <a href="https://www.tutorialspoint.com/pascal/pascal_overview.htm" target="_blank">teaching algorithms</a>.
Later dialects were used to develop several high profile software projects, including Skype, Photoshop, and
the original Mac OS. It is useful to consider as a precusor of Ada, sharing many points of functionality and style.</p>

<p><a href="https://www.rust-lang.org/" target="_blank">Rust</a> is the newest language here, created in 2010. It
is an odd mix of C and ML influence, placing more emphasis on the functional paradigm than other systems languages.
Its main claim to fame is adding another method of heap memory safety via
<a href="https://en.wikipedia.org/wiki/Substructural_type_system" target="_blank">affine typing</a>.</p>

<table id="lang">
    <tr>
        <td>
            <figure>
                <img src="/img/logo_d_small.png"
                     alt="Logo for the D programming language"
                     height="124"
                     width="164">
                <figcaption>D</figcaption>
            </figure>
        </td>
        <td>
            <figure>
                <img src="/img/logo_parasail_small.png"
                     alt="Logo for the Parasail programming language"
                     height="144"
                     width="149">
                <figcaption>Parasail</figcaption>
            </figure>
        </td>
    </tr>
    <tr>
        <td>
            <figure>
                <img src="/img/logo_pascal_small.png"
                     alt="A picture of Blaise Pascal to stand in as a logo for the Pascal programming language"
                     height="144"
                     width="142">
                <figcaption>Pascal*</figcaption>
            </figure>
        </td>
        <td>
            <figure>
                <img src="/img/logo_rust_small.png"
                     alt="Logo for the Rust programming language"
                     height="144"
                     width="144">
                <figcaption>Rust</figcaption>
            </figure>
        </td>
    </tr>
</table>

<p>* Pascal does not have an official logo, so a picture of <a href="https://en.wikipedia.org/wiki/Blaise_Pascal" target="_blank">Blaise Pascal</a>,
in whose honour the language is named, will have to do.</p>


<h5>Rules for Comparison</h5>

<p>The rule used for this article is that a language provides a feature if:</p>
<ol>
    <li>that feature is defined in the documents widely regarded as the language's defining document(s), <b>or</b></li>
    <li>that feature is widely implemented by compilers typically used for that language with essentially the same semantics.</li>
</ol>

<p>Note the bolded difference from the rules in Wheeler's paper. This is so later dialects of Pascal can be considered,
rather than strictly adhering to the ISO standard. The other three languages are unaffected by this change. Aside from
that, effort has been made to keep the evaluation as similar as practical to the previous work.</p>

<p>The defining documents used for each of these languages are as follows:</p>
<ul>
    <li>D: The <a href="https://dlang.org/spec/spec.html" target="_blank">D Language Specification</a> and the
        accompanying <a href="https://dlang.org/phobos/index.html" target="_blank">Library Reference</a>.</li>
    <li>Parasail: The <a href="https://forge.open-do.org/plugins/moinmoin/parasail/FrontPage?action=AttachFile&do=view&target=parasail_ref_manual.pdf" target="_blank">Parasail Reference Manual</a>.
        Parasail is still a work in progress, and no efforts to standardise it have yet been started.</li>
    <li>Pascal: ISO 7185 details Standard Pascal, and is available at several places in various formats. The copy used here
        was retrieved from <a href="http://www.pascal-central.com/standards.html" target="_blank">Pascal Central</a>.
        Checking for features of more recent Pascal dialects is done on a more ad hoc basis.</li>
    <li>Rust: The closest there is to a definition of the language is given in
        <a href="https://doc.rust-lang.org/reference/" target="_blank">The Rust Reference</a>. It should
        be noted that this document is not complete, nor stable. Supplementary information was obtained from
        <a href="https://rustbyexample.com/" target="_blank">Rust by Example</a>. No work to standardise
        Rust has been started yet either.</li>
</ul>


<h5>Results and Conclusions</h5>

<p>The appendix lists the Steelman requirements and how well each language supports them. The following table shows a
summary:</p>

<table id="results">
    <tr>
        <th>Language</th>
        <th>"No"</th>
        <th>"Partial"</th>
        <th>"Mostly"</th>
        <th>"Yes"</th>
        <th>Percentage with "Mostly" or "Yes"</th>
    </tr>
    <tr>
        <td>D</td>
        <td>7</td>
        <td>15</td>
        <td>25</td>
        <td>66</td>
        <td>81%</td>
    </tr>
    <tr>
        <td>Parasail</td>
        <td>11</td>
        <td>6</td>
        <td>11</td>
        <td>85</td>
        <td>85%</td>
    </tr>
    <tr>
        <td>Pascal</td>
        <td>19</td>
        <td>16</td>
        <td>11</td>
        <td>67</td>
        <td>69%</td>
    </tr>
    <tr>
        <td>Rust</td>
        <td>12</td>
        <td>19</td>
        <td>23</td>
        <td>59</td>
        <td>73%</td>
    </tr>
</table>

<p>Note that these raw numbers should not be taken at face value. They are a summary of how well the overall requirements are
met, no more, no less. Attention should be directed towards specific requirements to determine the strengths and weaknesses
of each language and the suitability for a particular purpose. Furthermore, some features are not covered by Steelman at all,
such as support for functional programming or object oriented programming.</p>

<p>The following are high level comments on these programming languages and how they relate:</p>
<ul>
    <li>All of these languages suffer from either not being standardised or, in the case of Pascal, having fragmented into
    multiple non-standard dialects afterwards. This impacts their scores for requirements 1H, 13A, 13B.</li>
    <li>Requirements 2A, 5D, 5E are perhaps not suitable to apply to today's programming languages, due to the presence of
    Unicode, functional programming, and use of initial values for safety guarantees respectively.</li>
    <li>Parasail scores very well on the Steelman, as expected from its Ada heritage and Ada having been explicitly designed to
    fit these requirements. Most of the "no" and "partial" items for Parasail are due to the lack of low level interfaces
    and pragmas (likely due to its experimental nature) and due to the pervasive implicit parallelism and increased
    static guarantees.</li>
    <li>D does significantly better than C, C++, or Java from the previous comparison due to the inclusion of new features
    such as parallelism into the language. Contracts in particular allow the subtyping requirements 3B, 3C, 3D to be at least
    partially satisfied. Most of its failures here can be attributed to its C legacy, including syntax, grammar, number of
    operator precedence levels, pointers, primitive type flexibility, and integer overflow handling. Noteworthy is the lack
    of a preprocessor.</li>
    <li>Pascal, at least the ISO standard variety, does not support parallelism and leaves a lot of error handling and floating
    point details up to implementation. Nonetheless its syntax, grammar, and more expressive type system (aside from the well
    known string length issue) contribute to its higher score compared to C.</li>
    <li>Rust lacks subtyping or contracts to emulate the requirements 3B, 3D, and its use of return values instead of exceptions
    leads to lower scores on 10A through 10G. The syntax is already notorious and the presence of macros may cause further
    issues. But it is definitely a significant improvement on C with an emphasis on immutability from its functional roots.
    The central failure of the language is the myopic focus on the affine typing solution to heap allocation and thread safety.
    The creators do not seem to realise that other solutions already exist, and that dynamic memory allocation is not the
    only safety issue a programmer has to cope with.</li>
    <li>Parasail and Ada remain the only languages so far considered that support fixed point types in the core language.</li>
    <li>Rust has by far the most support for the functional programming paradigm.</li>
</ul>


<h5>Appendix: Table Comparing the Languages to Steelman</h5>

<p>As in Wheeler's paper, this table shows each Steelman requirement on the left and then how well each of the four languages
considered meet that requirement on the right. Some explanatory notes are included for a few of the requirements.</p>

<p>Note that due to the standardisation issues each of these languages has, a (fortunately quite low) number of these
turned out to be educated guesses. Fairness was the goal, but nonetheless reader discretion is advised.</p>


<section class="accordian">
    <input type="checkbox" name="collapse" id="handle1">
    <label for="handle1">Toggle Appendix Table</label>
    <div class="hidden_content">

<table id="appendix">
    <tr>
        <th style="width: 30em">Requirement</th>
        <th style="width: 7.5em">D</th>
        <th style="width: 7.5em">Parasail</th>
        <th style="width: 7.5em">Pascal</th>
        <th style="width: 7.5em">Rust</th>
    </tr>

    <tr>
        <td rowspan="2">
            1A. Generality. The language shall provide generality only to the extent necessary
            to satisfy the needs of embedded computer applications. Such applications involve
            real time control, self diagnostics, input-output to nonstandard peripheral devices,
            parallel processing, numeric computation, and file processing.
        </td>
        <td class="yn">yes</td>
        <td class="yn">no?</td>
        <td class="yn">yes?</td>
        <td class="yn">yes?</td>
    </tr>
    <tr>
        <td colspan="4">
            Parasail does not specify ways to directly control hardware, nor any interfaces to other languages.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            1B. Reliability. The language should aid the design and development of reliable
            programs. The language shall be designed to avoid error prone features and to
            maximize automatic detection of programming errors. The language shall require some
            redundant, but not duplicative, specifications in programs. Translators shall produce
            explanatory diagnostic and warning messages, but shall not attempt to correct
            programming errors.
        </td>
        <td class="yn">yes?</td>
        <td class="yn">yes</td>
        <td class="yn">partial?</td>
        <td class="yn">mostly?</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            1C. Maintainability. The language should promote ease of program maintenance. It
            should emphasize program readability (i.e., clarity, understandability, and modifiability
            of programs). The language should encourage user documentation of programs. It shall
            require explicit specification of programmer decisions and shall provide defaults only
            for instances where the default is stated in the language definition, is always meaningful,
            reflects the most frequent usage in programs, and may be explicitly overridden.
        </td>
        <td class="yn">partial?</td>
        <td class="yn">yes?</td>
        <td class="yn">mostly?</td>
        <td class="yn">partial?</td>
    </tr>
    <tr>
        <td colspan="4">
            Parasail was designed with readability in mind, although it suffers slightly from having several
            different ways to do something. Pascal was designed for teaching structured programming. D inherits
            a lot of the syntactical traps of C-family languages. Rust has exceedingly terse and difficult to
            read syntax.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            1D. Efficiency. The language design should aid the production of efficient object programs.
            Constructs that have unexpectedly expensive implementations should be easily recognizable
            by translators and by users. Features should be chosen to have a simple and efficient
            implementation in many object machines, to avoid execution costs for available generality
            where it is not needed, to maximize the number of safe optimizations available to
            translators, and to ensure that unused and constant portions of programs will not add to
            execution costs. Execution time support packages of the language shall not be included in
            object code unless they are called.
        </td>
        <td class="yn">partial?</td>
        <td class="yn">yes?</td>
        <td class="yn">yes</td>
        <td class="yn">yes?</td>
    </tr>
    <tr>
        <td colspan="4">
            D incorporates garbage collection to some extent. Parasail is designed to allow as much implicit
            parallelism as possible.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            1E. Simplicity. The language should not contain unnecessary complexity. It should have a
            consistent semantic structure that minimizes the number of underlying concepts. It should
            be as small as possible consistent with the needs of the intended applications. It should
            have few special cases and should be composed from features that are individually simple
            in their semantics. The language should have uniform syntactic conventions and should not
            provide several notations for the same concept. No arbitrary restriction should be imposed
            on a language feature.
        </td>
        <td class="yn">yes?</td>
        <td class="yn">mostly</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            Parasail allows several syntactical forms that are identical in meaning.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            1F. Implementability. The language shall be composed from features that are understood and
            can be implemented. The semantics of each feature should be sufficiently well specified and
            understandable that it will be possible to predict its interaction with other features. To
            the extent that it does not interfere with other requirements, the language shall facilitate
            the production of translators that are easy to implement and are efficient during translation.
            There shall be no language restrictions that are not enforceable by translators.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            All of these languages have been reasonably implemented.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            1G. Machine Independence. The design of the language should strive for machine independence.
            It shall not dictate the characteristics of object machines or operating systems except to the
            extent that such characteristics are implied by the semantics of control structures and built-in
            operations. It shall attempt to avoid features whose semantics depend on characteristics of the
            object machine or of the object machine operating system. Nevertheless, there shall be a facility
            for defining those portions of programs that are dependent on the object machine configuration
            and for conditionally compiling programs depending on the actual configuration.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            1H. Complete Definition. The language shall be completely and unambiguously defined. To the extent
            that a formal definition assists in achieving the above goals (i.e., all of section 1), the
            language shall be formally defined.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">mostly?</td>
        <td class="yn">mostly?</td>
    </tr>
    <tr>
        <td colspan="4">
            While Pascal is the only one of these languages with an ISO standard, most Pascal programming is done
            with more recent extended dialects. Rust reference material does not completely describe the language.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            2A. Character Set. The full set of character graphics that may be used in source programs shall be
            given in the language definition. Every source program shall also have a representation that uses
            only the following 55 character subset of the ASCII graphics: &#37;&amp;'()*+,-./:;&lt;=&gt;? 0123456789
            ABCDEFGHIJKLMNOPQRSTUVWXYZ_ Each additional graphic (i.e., one in the full set but not in the 55
            character set) may be replaced by a sequence of (one or more) characters from the 55 character set
            without altering the semantics of the program. The replacement sequence shall be specified in the
            language definition.
        </td>
        <td class="yn">mostly</td>
        <td class="yn">mostly</td>
        <td class="yn">mostly</td>
        <td class="yn">mostly</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            2B. Grammar. The language should have a simple, uniform, and easily parsed grammar and lexical
            structure. The language shall have free form syntax and should use familiar notations where such
            use does not conflict with other goals.
        </td>
        <td class="yn">partial?</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">partial?</td>
    </tr>
    <tr>
        <td colspan="4">
            Use of familiar notations is something that Parasail arguably takes too far, see 1E. D inherits some
            grammar issues from C/C++. Rust has less borrowing from that source but is still very ad hoc.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            2C. Syntactic Extensions. The user shall not be able to modify the source language syntax. In
            particular the user shall not be able to introduce new precedence rules or to define new syntactic
            forms.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">no</td>
    </tr>
    <tr>
        <td colspan="4">
            Rust has macros, which can be used to add new syntax to the language.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            2D. Other Syntactic Issues. Multiple occurrences of a language defined symbol appearing in the same
            context shall not have essentially different meanings. Lexical units (i.e., identifiers, reserved
            words, single and multicharacter symbols, numeric and string literals, and comments) may not cross
            line boundaries of a source program. All key word forms that contain declarations or statements
            shall be bracketed (i.e., shall have a closing as well as an opening key word). Programs may not
            contain unmatched brackets of any kind.
        </td>
        <td class="yn">mostly</td>
        <td class="yn">yes</td>
        <td class="yn">mostly</td>
        <td class="yn">mostly</td>
    </tr>
    <tr>
        <td colspan="4">
            D, Pascal, and Rust permit multi line comments. D and Rust use opening and closing braces rather
            than key words.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            2E. Mnemonic Identifiers. Mnemonically significant identifiers shall be allowed. There shall be a
            break character for use within identifiers. The language and its translators shall not permit
            identifiers or reserved words to be abbreviated. (Note that this does not preclude reserved words
            that are abbreviations of natural language words.)
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            2F. Reserved Words. The only reserved words shall be those that introduce special syntactic forms
            (such as control structures and declarations) or that are otherwise used as delimiters. Words that
            may be replaced by identifiers, shall not be reserved (e.g., names of functions, types, constants,
            and variables shall not be reserved). All reserved words shall be listed in the language definition.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            2G. Numeric Literals. There shall be built-in decimal literals. There shall be no implicit truncation
            or rounding of integer and fixed point literals.
        </td>
        <td class="yn">mostly</td>
        <td class="yn">yes</td>
        <td class="yn">mostly?</td>
        <td class="yn">mostly</td>
    </tr>
    <tr>
        <td colspan="4">
            Parasail Univ_Integer and Univ_Real types provide arbitrary precision. Rust provides configurable ways
            to treat integer overflow, with the default release mode being wrapping by two's complement. D allows
            implicit wrapping of integers. Pascal real types are implementation defined. Only Parasail supports
            fixed point types.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            2H. String Literals. There shall be a built-in facility for fixed length string literals. String
            literals shall be interpreted as one-dimensional character arrays.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            Univ_Strings in Parasail are vectors of Univ_Character, not arrays.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            2I. Comments. The language shall permit comments that are introduced by a special (one or two character)
            symbol and terminated by the next line boundary of the source program.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">partial</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            Line comments were introduced in Turbo Pascal, but are not part of the ISO standard.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3A. Strong Typing. The language shall be strongly typed. The type of each variable, array and record
            component, expression, function, and parameter shall be determinable during translation.
        </td>
        <td class="yn">mostly</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            Some implicit conversion is allowed in D, such as booleans to integral types, one way conversion from
            enums to integers, and some automatic promotion of integer types.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3B. Type Conversions. The language shall distinguish the concepts of type (specifying data elements with
            common properties, including operations), subtype (i.e., a subset of the elements of a type, that is
            characterized by further constraints), and representations (i.e., implementation characteristics). There
            shall be no implicit conversions between types. Explicit conversion operations shall be automatically
            defined between types that are characterized by the same logical properties.
        </td>
        <td class="yn">partial?</td>
        <td class="yn">yes</td>
        <td class="yn">yes?</td>
        <td class="yn">partial?</td>
    </tr>
    <tr>
        <td colspan="4">
            D, Rust do not have subtypes, although class structures in D can be used with contract programming to
            provide the same functionality. D allows implicit promotion of integer types. D, Rust have primitive types
            that are tightly coupled to the typical implementation characteristics of computer hardware.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3C. Type Definitions. It shall be possible to define new data types in programs. A type may be defined
            as an enumeration, an array or record type, an indirect type, an existing type, or a subtype of an existing
            type. It shall be possible to process type definitions entirely during translation. An identifier may be
            associated with each type. No restriction shall be imposed on user defined types unless it is imposed on
            all types.
        </td>
        <td class="yn">mostly</td>
        <td class="yn">yes</td>
        <td class="yn">yes?</td>
        <td class="yn">mostly</td>
    </tr>
    <tr>
        <td colspan="4">
            D, Rust do not have subtypes. D however can emulate similar functionality with type invariant contracts
            for user defined classes.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3D. Subtype Constraints. The constraints that characterize subtypes shall include range, precision, scale,
            index ranges, and user defined constraints. The value of a subtype constraint for a variable may be
            specified when the variable is declared. The language should encourage such specifications. [Note that
            such specifications can aid the clarity, efficiency, maintainability, and provability of programs.]
        </td>
        <td class="yn">partial</td>
        <td class="yn">yes?</td>
        <td class="yn">mostly?</td>
        <td class="yn">no</td>
    </tr>
    <tr>
        <td colspan="4">
            D does not have subtypes but has similar functionality with class type invariants. Rust doesn't have
            subtypes at all.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-1A. Numeric Values. The language shall provide distinct numeric types for exact and for approximate
            computation. Numeric operations and assignment that would cause the most significant digits of numeric
            values to be truncated (e.g., when overflow occurs) shall constitute an exception situation.
        </td>
        <td class="yn">partial?</td>
        <td class="yn">yes</td>
        <td class="yn">partial?</td>
        <td class="yn">mostly?</td>
    </tr>
    <tr>
        <td colspan="4">
            Numeric overflow does not cause an exception in D, but the language provides standard ways to check for
            the situation. Overflow error handling in Pascal is implementation defined.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-1B. Numeric Operations. There shall be built-in operations (i.e., functions) for conversion between
            the numeric types. There shall be operations for addition, subtraction, multiplication, division, negation,
            absolute value, and exponentiation to integer powers for each numeric type. There shall be built-in
            equality (i.e., equal and unequal) and ordering operations (i.e., less than, greater than, less than or
            equal, and greater than or equal) between elements of each numeric type. Numeric values shall be equal
            if and only if they have exactly the same abstract value.
        </td>
        <td class="yn">mostly</td>
        <td class="yn">yes</td>
        <td class="yn">mostly</td>
        <td class="yn">mostly</td>
    </tr>
    <tr>
        <td colspan="4">
            D uses a library abs() function instead of a built-in operator. Pascal does not have built-in operators
            for absolute value or exponentiation. Rust uses library abs() and pow() functions instead of built-in
            absolute value and exponentiation operators.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-1C. Numeric Variables. The range of each numeric variable must be specified in programs and shall be
            determined by the time of its allocation. Such specifications shall be interpreted as the minimum range
            to be implemented and as the maximum range needed by the application. Explicit conversion operations shall
            not be required between numeric ranges.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            Counting built-in integer types as specifying a range, all these languages do so to some extent. Parasail
            is the only one that supports user defined custom ranges.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-1D. Precision. The precision (of the mantissa) of each expression result and variable in approximate
            computations must be specified in programs, and shall be determinable during translation. Precision
            specifications shall be required for each such variable. Such specifications shall be interpreted as the
            minimum accuracy (not significance) to be implemented. Approximate results shall be implicitly rounded to
            the implemented precision. Explicit conversions shall not be required between precisions.
        </td>
        <td class="yn">mostly</td>
        <td class="yn">yes</td>
        <td class="yn">no</td>
        <td class="yn">mostly</td>
    </tr>
    <tr>
        <td colspan="4">
            D defines specific precisions for double and float, along with a minimum precision for real. Custom
            precisions can be defined for storage only, but all operations happen on doubles/floats/reals. In
            Standard Pascal precision of real number types is entirely implementation defined. Rust defines
            specific precisions for 32 and 64 bit floats, but no other control over precision.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-1E. Approximate Arithmetic Implementation. Approximate arithmetic will be implemented using the actual
            precisions, radix, and exponent range available in the object machine. There shall be built-in operations
            to access the actual precision, radix, and exponent range of the implementation.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes?</td>
        <td class="yn">partial</td>
        <td class="yn">yes?</td>
    </tr>
    <tr>
        <td colspan="4">
            In Standard Pascal the values taken by real number types are entirely implementation defined. In practice,
            this usually means implementation using the actual precisions available in the object machine.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-1F. Integer and Fixed Point Numbers. Integer and fixed point numbers shall be treated as exact numeric
            values. There shall be no implicit truncation or rounding in integer and fixed point computations.
        </td>
        <td class="yn">mostly</td>
        <td class="yn">yes</td>
        <td class="yn">partial</td>
        <td class="yn">mostly</td>
    </tr>
    <tr>
        <td colspan="4">
            D, Pascal, Rust don't support fixed point numbers, and permit implicit wrapping with integer calculations.
            Dealing with overflow, wrapping, and other error conditions in Pascal is implementation defined.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-1G. Fixed Point Scale. The scale or step size (i.e., the minimal representable difference between
            values) of each fixed point variable must be specified in programs and be determinable during translation.
            Scales shall not be restricted to powers of two.
        </td>
        <td class="yn">no</td>
        <td class="yn">yes</td>
        <td class="yn">no</td>
        <td class="yn">no</td>
    </tr>
    <tr>
        <td colspan="4">
            Of these four languages, inly Parasail supports fixed point types.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-1H. Integer and Fixed Point Operations. There shall be integer and fixed point operations for modulo
            and integer division and for conversion between values with different scales. All built-in and predefined
            operations for exact arithmetic shall apply between arbitrary scales. Additional operations between
            arbitrary scales shall be definable within programs.
        </td>
        <td class="yn">no</td>
        <td class="yn">yes</td>
        <td class="yn">no</td>
        <td class="yn">no</td>
    </tr>
    <tr>
        <td colspan="4">
            All support "modulo" operators; D, Pascal, Rust don't support fixed point numbers.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-2A. Enumeration Type Definitions. There shall be types that are definable in programs by enumeration of
            their elements. The elements of an enumeration type may be identifiers or character literals. Each
            variable of an enumeration type may be restricted to a contiguous subsequence of the enumeration.
        </td>
        <td class="yn">mostly</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">mostly</td>
    </tr>
    <tr>
        <td colspan="4">
            D does not permit character literals in an enumeration, nor restriction to a subsequence. Rust enums are
            more flexible in content, but still don't support restriction to a subsequence.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-2B. Operations on Enumeration Types. Equality, inequality, and the ordering operations shall be
            automatically defined between elements of each enumeration type. Sufficient additional operations shall be
            automatically defined so that the successor, predecessor, the position of any element, and the first and
            last element of the type may be computed.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes?</td>
        <td class="yn">yes?</td>
        <td class="yn">mostly?</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-2C. Boolean Type. There shall be a predefined type for Boolean values.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            D's boolean type is weakly typed.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-2D. Character Types. Character sets shall be definable as enumeration types. Character types may contain
            both printable and control characters. The ASCII character set shall be predefined.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-3A. Composite Type Definitions. It shall be possible to define types that are Cartesian products of other
            types. Composite types shall include arrays (i.e., composite data with indexable components of homogeneous
            types) and records (i.e., composite data with labeled components of heterogeneous type).
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            All have arrays and records.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-3B. Component Specifications. For elements of composite types, the type of each component (i.e., field)
            must be explicitly specified in programs and determinable during translation. Components may be of any type
            (including array and record types). Range, precision, and scale specifications shall be required for each
            component of appropriate numeric type.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            Range, precision, and scale specifications are included in numeric type definitions (with support varying,
            see 3-1).
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-3C. Operations on Composite Types. A value accessing operation shall be automatically defined for each
            component of composite data elements. Assignment shall be automatically defined for components that have
            alterable values. A constructor operation (i.e., an operation that constructs an element of a type from its
            constituent parts) shall be automatically defined for each composite type. An assignable component may be
            used anywhere in a program that a variable of the component's type is permitted. There shall be no automatically
            defined equivalence operations between values of elements of a composite type.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-3D. Array Specifications. Arrays that differ in number of dimensions or in component type shall be of
            different types. The range of subscript values for each dimension must be specified in programs and may be
            determinable at the time of array allocation. The range of each subscript value must be restricted to a
            contiguous sequence of integers or to a contiguous sequence from an enumeration type.
        </td>
        <td class="yn">mostly</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">mostly</td>
    </tr>
    <tr>
        <td colspan="4">
            D and Rust array indexes can only start at zero and cannot use enumerations.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-3E. Operations on Subarrays. There shall be built-in operations for value access, assignment, and
            catenation of contiguous sections of one-dimensional arrays of the same component type. The results of such
            access and catenation operations may be used as actual input parameter.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes?</td>
        <td class="yn">no</td>
        <td class="yn">partial</td>
    </tr>
    <tr>
        <td colspan="4">
            Pascal has extremely limited array slicing and does not have a built-in array concatenation operator. Rust
            has array slicing facilities, but lacks a built-in array concatenation operator.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-3F. Nonassignable Record Components. It shall be possible to declare constants and (unary) functions that
            may be thought of as record components and may be referenced using the same notation as for accessing record
            components. Assignment shall not be permitted to such components.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">no?</td>
        <td class="yn">no?</td>
    </tr>
    <tr>
        <td colspan="4">
            D classes can include constants and functions. Parasail type inferfaces can include constants and functions.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-3G. Variants. It shall be possible to define types with alternative record structures (i.e., variants).
            The structure of each variant shall be determinable during translation.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes?</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            D classes can be used to simulate runtime variants. D also has untagged unions. Pascal has variant records.
            Rust has tagged unions called "sum types".
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-3H. Tag Fields. Each variant must have a nonassignable tag field (i.e., a component that can be used to
            discriminate among the variants during execution). It shall not be possible to alter a tag field without
            replacing the entire variant.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes?</td>
        <td class="yn">yes?</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-3I. Indirect Types. It shall be possible to define types whose elements are indirectly accessed. Elements
            of such types may have components of their own type, may have substructure that can be altered during execution,
            and may be distinct while having identical component values. Such types shall be distinguishable from other
            composite types in their definitions. An element of an indirect type shall remain allocated as long as it can
            be referenced by the program. [Note that indirect types require pointers and sometimes heap storage in their
            implementation.]
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-3J. Operations on Indirect Types. Each execution of the constructor operation for an indirect type shall
            create a distinct element of the type. An operation that distinguishes between different elements, an
            operation that replaces all of the component values of an element without altering the element's identity,
            and an operation that produces a new element having the same component values as its argument, shall be
            automatically defined for each indirect type.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-4A. Bit Strings (i.e., Set Types). It shall be possible to define types whose elements are
            one-dimensional Boolean arrays represented in maximally packed form (i.e, whose elements are sets).
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">partial</td>
    </tr>
    <tr>
        <td colspan="4">
            D provides bit arrays in the standard library in std.bitmanip. It is easy enough to construct bit
            strings in Rust using structs or integer types, but the language itself does not provide them as
            built in functionality.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-4B. Bit String Operations. Set construction, membership (i.e., subscription), set equivalence
            and nonequivalence, and also complement, intersection, union, and symmetric difference (i.e.,
            component-by-component negation, conjunction, inclusive disjunction, and exclusive disjunction
            respectively) operations shall be defined automatically for each set type.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes?</td>
        <td class="yn">yes</td>
        <td class="yn">partial</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-5A. Encapsulated Definitions. It shall be possible to encapsulate definitions. An encapsulation
            may contain declarations of anything (including the data elements and operations comprising a type)
            that is definable in programs. The language shall permit multiple explicit instantiations of an
            encapsulation.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            All of these languages have modules as their unit of encapsulation.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-5B. Effect of Encapsulation. An encapsulation may be used to inhibit external access to
            implementation properties of the definition. In particular, it shall be possible to prevent external
            reference to any declaration within the encapsulation including automatically defined operations
            such as type conversions and equality. Definitions that are made within an encapsulation and are
            externally accessible may be renamed before use outside the encapsulation.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            3-5C. Own Variables. Variables declared within an encapsulation, but not within a function, procedure,
            or process of the encapsulation, shall remain allocated and retain their values throughout the scope
            in which the encapsulation is instantiated.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            4A. Form of Expressions. The parsing of correct expressions shall not depend on the types of their
            operands or on whether the types of the operands are built into the language.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            4B. Type of Expressions. It shall be possible to specify the type of any expression explicitly.
            The use of such specifications shall be required only where the type of the expression cannot be
            uniquely determined during translation from the context of its use (as might be the case with a
            literal).
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            4C. Side Effects. The language shall attempt to minimize side effects in expressions, but shall
            not prohibit all side effects. A side effect shall not be allowed if it would alter the value
            of a variable that can be accessed at the point of the expression. Side effects shall be limited
            to own variables of encapsulations. The language shall permit side effects that are necessary
            to instrument functions and to do storage management within functions. The order of side effects
            within an expression shall not be guaranteed. [Note that the latter implies that any program
            that depends on the order of side effects is erroneous.]
        </td>
        <td class="yn">mostly?</td>
        <td class="yn">yes?</td>
        <td class="yn">mostly?</td>
        <td class="yn">mostly?</td>
    </tr>
    <tr>
        <td colspan="4">
            Parasail does not permit global variables.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            4D. Allowed Usage. Expressions of a given type shall be allowed wherever both constants and
            variables of the type are allowed.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            4E. Translation Time Expressions. Expressions that can be evaluated during translation shall
            be permitted wherever literals of the type are permitted. Translation time expressions that
            include only literals and the use of translation time facilities (see 11C) shall be
            evaluated during translation.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            4F. Operator Precedence Levels. The precedence levels (i.e., binding strengths) of all (prefix
            and infix) operators shall be specified in the language definition, shall not be alterable by
            the user, shall be few in number, and shall not depend on the types of the operands.
        </td>
        <td class="yn">mostly</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">mostly</td>
    </tr>
    <tr>
        <td colspan="4">
            Pascal has 5 levels, Parasail has 7, Rust has 13 and D has 15-19 depending on how you count them.
            For comparison, Ada has 6.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            4G. Effect of Parentheses. If present, explicit parentheses shall dictate the association of
            operands with operators. The language shall specify where explicit parentheses are required
            and shall attempt to minimize the psychological ambiguity in expressions. [Note that this
            might be accomplished by requiring explicit parentheses to resolve the operator-operand
            association whenever a nonassociative operator appears to the left of an operator of the same
            precedence at the least-binding precedence level of any subexpression.]
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            5A. Declarations of Constants. It shall be possible to declare constants of any type. Such
            constants shall include both those whose values-are determined during translation and those
            whose value cannot be determined until allocation. Programs may not assign to constants.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            5B. Declarations of Variables. Each variable must be declared explicitly. Variables may be
            of any type. The type of each variable must be specified as part of its declaration and must
            be determinable during translation. [Note, "variable" throughout this document refers not
            only to simple variables but also to composite variables and to components of arrays and records.]
        </td>
        <td class="yn">mostly</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">partial</td>
    </tr>
    <tr>
        <td colspan="4">
            D permits "void *" as a type, which is really a pointer to an unknown type and subverts the type system.
            Rust does not require the type of each variable to be explicitly specified and will infer types instead.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            5C. Scope of Declarations. Everything (including operators) declared in a program shall have
            a scope (i.e., a portion of the program in which it can be referenced). Scopes shall be
            determinable during translation. Scopes may be nested (i.e., lexically embedded). A declaration
            may be made in any scope. Anything other than a variable shall be accessable within any nested
            scope of its definition.
        </td>
        <td class="yn">yes?</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes?</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            5D. Restrictions on Values. Procedures, functions, types, labels, exception situations, and
            statements shall not be assignable to variables, be computable as values of expressions, or
            be usable as nongeneric parameters to procedures or functions.
        </td>
        <td class="yn">no</td>
        <td class="yn">no</td>
        <td class="yn">no?</td>
        <td class="yn">no</td>
    </tr>
    <tr>
        <td colspan="4">
            D and Pascal allow pointers to functions. Parasail allows lambda expressions. Rust has first class functions.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            5E. Initial Values. There shall be no default initial-values for variables.
        </td>
        <td class="yn">partial</td>
        <td class="yn">partial</td>
        <td class="yn">partial?</td>
        <td class="yn">mostly</td>
    </tr>
    <tr>
        <td colspan="4">
            D defines initial values for all types. Parasail sets initial values of all 'optional' types to null. Rust
            does not assign default initial values, but instead requires the programmer to always provide an initial
            value. All of these instances are done to support reliability.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            5F. Operations on Variables. Assignment and an implicit value access operation shall be
            automatically defined for each variable.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            5G. Scope of Variables. The language shall distinguish between open scopes (i.e., those that
            are automatically included in the scope of more globally declared variables) and closed scopes
            (i.e., those in which nonlocal variables must be explicitly Imported). Bodies of functions,
            procedures, and processes shall be closed scopes. Bodies of classical control structures shall
            be open scopes.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            6A. Basic Control Facility. The (built-in) control mechanisms should be of minimal number and
            complexity. Each shall provide a single capability and shall have a distinguishing syntax.
            Nesting of control structures shall be allowed. There shall be no control definition facility.
            Local scopes shall be allowed within the bodies of control statements. Control structures shall
            have only one entry point and shall exit to a single point unless exited via an explicit
            transfer of control (where permitted, see 6G), or the raising of an exception (see 10C).
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            6B. Sequential Control. There shall be a control mechanism for sequencing statements. The
            language shall not impose arbitrary restrictions on programming style, such as the choice
            between statement terminators and statement separators, unless the restriction makes programming
            errors less likely.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            D and Rust use statement terminators. Pascal and Parasail use statement separators.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            6C. Conditional Control. There shall be conditional control structures that permit selection
            among alternative control paths. The selected path may depend on the value of a Boolean expression,
            on a computed choice among labeled alternatives, or on the true condition in a set of conditions.
            The language shall define the control action for all values of the discriminating condition
            that are not specified by the program. The user may supply a single control path to be used
            when no other path is selected. Only the selected branch shall be compiled when the discriminating
            condition is a translation time expression.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            6D. Short Circuit Evaluation. There shall be infix control operations for short circuit conjunction
            and disjunction of the controlling Boolean expression in conditional and iterative control structures.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">partial</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            Standard Pascal does not provide infix control operations, but both Extended Pascal and Turbo Pascal do.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            6E. Iterative Control. There shall be an iterative control structure. The iterative control may
            be exited (without reentry) at an unrestricted number of places. A succession of values from an
            enumeration type or the integers may be associated with successive iterations and the value for
            the current iteration accessed as a constant throughout the loop body.
        </td>
        <td class="yn">mostly</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            In D, the loop control variable is not considered a constant.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            6G. Explicit Control Transfer. There shall be a mechanism for control transfer (i.e., the go to).
            It shall not be possible to transfer out of closed scopes, into narrower scopes, or into control
            structures. It shall be possible to transfer out of classical control structures. There shall be
            no control transfer mechanisms in the form of switches, designational expressions, label variables,
            label parameters, or alter statements.
        </td>
        <td class="yn">yes?</td>
        <td class="yn">partial</td>
        <td class="yn">yes</td>
        <td class="yn">partial?</td>
    </tr>
    <tr>
        <td colspan="4">
            Neither Parasail nor Rust support goto. However both support break/continue statements that serve
            the same purpose in many cases.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            7A. Function and Procedure Definitions. Functions (which return values to expressions) and procedures
            (which can be called as statements) shall be definable in programs. Functions or procedures that
            differ in the number or types of their parameters may be denoted by the same identifier or operator
            (i.e., overloading shall be permitted). [Note that redefinition, as opposed to overloading, of an
            existing function or procedure is often error prone.]
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">no</td>
    </tr>
    <tr>
        <td colspan="4">
            Rust does not support ad-hoc polymorphism. It must be emulated using the trait system.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            7B. Recursion. It shall be possible to call functions and procedures recursively.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            &nbsp;
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            7C. Scope Rules. A reference to an identifier that is not declared in the most local scope
            shall refer to a program element that is lexically global, rather than to one that is global
            through the dynamic calling structure.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            7D. Function Declarations. The type of the result for each function must be specified in its
            declaration and shall be determinable during translation. The results of functions may be of
            any type. If a result is of a nonindirect array or record type then the number of its components
            must be determinable by the time of function call.
        </td>
        <td class="yn">mostly</td>
        <td class="yn">mostly</td>
        <td class="yn">mostly?</td>
        <td class="yn">mostly</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            7F. Formal Parameter Classes. There shall be three classes of formal data parameters: (a) input
            parameters, which act as constants that are initialized to the value of corresponding actual
            parameters at the time of call, (b) input-output parameters, which enable access and assignment
            to the corresponding actual parameters, either throughout execution or only upon call and prior
            to any exit, and (c) output parameters, whose values are transferred to the corresponding actual
            parameter only at the time of normal exit. In the latter two cases the corresponding actual
            parameter shall be determined at time of call and must be a variable or an assignable component
            of a composite type.
        </td>
        <td class="yn">partial</td>
        <td class="yn">yes</td>
        <td class="yn">partial?</td>
        <td class="yn">partial?</td>
    </tr>
    <tr>
        <td colspan="4">
            D, Pascal and Rust do not identify in, in-out and out parameters. D, Pascal and Rust can support
            in-only parameters.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            7G. Parameter Specifications. The type of each formal parameter must be explicitly specified in
            programs and shall be determinable during translation. Parameters may be of any type. The
            language shall not require user specification of subtype constraints for formal parameters. If
            such constraints are permitted they shall be interpreted as assertions and not as additional
            overloading. Corresponding formal and actual parameters must be of the same type.
        </td>
        <td class="yn">yes?</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes?</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            7H. Formal Array Parameters. The number of dimensions for formal array parameters must be
            specified in programs and shall be determinable during translation. Determination of the
            subscript range for formal array parameters may be delayed until invocation and may vary from
            call to call. Subscript ranges shall be accessible within function and procedure bodies without
            being passed as explicit parameters.
        </td>
        <td class="yn">no</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">no</td>
    </tr>
    <tr>
        <td colspan="4">
            Subscript ranges are not accessible in D or Rust.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            7I. Restrictions to Prevent Aliasing. The language shall attempt to prevent aliasing (l.e., multiple
            access paths to the same variable or record component) that is not intended, but shall not prohibit
            all aliasing. Aliasing shall not be permitted between output parameters nor between an input-output
            parameter and a nonlocal variable. Unintended aliasing shall not be permitted between input-output
            parameters. A restriction limiting actual input-output parameters to variables that are nowhere
            referenced as nonlocals within a function or routine, is not prohibited. All aliasing of components
            of elements of an indirect type shall be considered intentional.
        </td>
        <td class="yn">no</td>
        <td class="yn">yes</td>
        <td class="yn">yes?</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            8A. Low Level Input-Output. There shall be a few low level input-output operations that send and
            receive control information to and from physical channels and devices. The low level operations
            shall be chosen to insure that all user level input-output operations can be defined within the language.
        </td>
        <td class="yn">partial?</td>
        <td class="yn">no?</td>
        <td class="yn">partial?</td>
        <td class="yn">no?</td>
    </tr>
    <tr>
        <td colspan="4">
            D and some Pascal dialects permit access to memory mapped locations.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            8B. User Level Input-Output. The language shall specify (i.e., give calling format and general
            semantics) a recommended set of user level input-output operations. These shall include operations
            to create, delete, open, close, read, write, position, and interrogate both sequential and random
            access files and to alter the association between logical files and physical devices.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            8C. Input Restrictions. User level input shall be restricted to data whose record representations
            are known to the translator (i.e., data that is created and written entirely within the program
            or data whose representation is explicitly specified in the program).
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            8D. Operating System Independence. The language shall not require the presence of an operating
            system. [Note that on many machines it will be necessary to provide run-time procedures to
            implement some features of the language.]
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            8E. Resource Control. There shall be a few low level operations to interrogate and control
            physical resources (e.g., memory or processors) that are managed (e.g., allocated or scheduled)
            by built-in features of the language.
        </td>
        <td class="yn">mostly</td>
        <td class="yn">mostly</td>
        <td class="yn">partial</td>
        <td class="yn">no</td>
    </tr>
    <tr>
        <td colspan="4">
            D supports custom garbage collection and thread priorities. Standard Pascal does not define ways to
            control physical resources, but popular implementations such as Free Pascal provide both custom memory
            management and thread facilities.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            8F. Formating. There shall be predefined operations to convert between the symbolic and internal
            representation of all types that have literal forms in the language (e.g., strings of digits to
            integers, or an enumeration element to its symbolic form). These conversion operations shall
            have the same semantics as those specified for literals in programs.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">partial</td>
    </tr>
    <tr>
        <td colspan="4">
            In Rust, operations to convert between enumerations and strings are not predefined.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            9A. Parallel Processing. It shall be possible to define parallel processes. Processes (i.e., activation
            instances of such a definition) may be initiated at any point within the scope of the definition.
            Each process (activation) must have a name. It shall not be possible to exit the scope of a process
            name unless the process is terminated (or uninitiated).
        </td>
        <td class="yn">yes</td>
        <td class="yn">mostly</td>
        <td class="yn">no</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            D provides this functionality with the std.parallelism and core.thread libraries. Rust provides this
            with the std::thread library. Parasail is designed to be implicitly parallel by default, and thus the
            lightweight threads used do not have names. Pascal does not have built in thread or process facilities,
            and must rely on operating system specific libraries.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            9B. Parallel Process Implementation. The parallel processing facility shall be designed to minimize
            execution time and space. Processes shall have consistent semantics whether implemented on multicomputers,
            multiprocessors, or with interleaved execution on a single processor.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">no</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            9C. Shared Variables and Mutual Exclusion. It shall be.possible to mark variables that are shared
            among parallel processes. An unmarked variable that is assigned on one path and used on another
            shall cause a warning. It shall be possible efficiently to perform mutual exclusion in programs.
            The language shall not require any use of mutual exclusion.
        </td>
        <td class="yn">partial?</td>
        <td class="yn">yes</td>
        <td class="yn">no</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            D supports shared variables and atomic operations, however the idiomatic way of threading is to
            rely on immutable data and message passing.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            9D. Scheduling. The semantics of the built-in scheduling algorithm shall be first-in-first-out
            within priorities. A process may alter its own priority. If the language provides a default
            priority for new processes it shall be the priority of its initiating process. The built-in
            scheduling algorithm shall not require that simultaneously executed processes on different
            processors have the same priority. [Note that this rule gives maximum scheduling control to the
            user without loss of efficiency. Note also that priority specification does not impose a specific
            execution order among parallel paths and thus does not provide a means for mutual exclusion.]
        </td>
        <td class="yn">yes?</td>
        <td class="yn">yes?</td>
        <td class="yn">no</td>
        <td class="yn">partial?</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            9E. Real Time. It shall be possible to access a real time clock. There shall be translation time
            constants to convert between the implementation units and the program units for real time. On any
            control path, it shall be possible to delay until at least a specified time before continuing
            execution. A process may have an accessible clock giving the cumulative processing time (i.e., CPU
            time) for that process.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes?</td>
        <td class="yn">yes?</td>
    </tr>
    <tr>
        <td colspan="4">
            D provides this in core.time. Parasail provides this in its standard library.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            9G. Asynchronous Termination. It shall be possible to terminate another process. The terminated
            process may designate the sequence of statements it will execute in response to the induced termination.
        </td>
        <td class="yn">yes</td>
        <td class="yn">no?</td>
        <td class="yn">no</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            D achieves this with std.parallelism and std.process. Pascal programs call an operating system dependent
            library to perform this. Parasail is structured around implicit pervasive parallelism so it's questionable
            how applicable this requirement is. Rust achieves this with std::process::Child.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            9H. Passing Data. It shall be possible to pass data between processes that do not share variables.
            It shall be possible to delay such data transfers until both the sending and receiving processes
            have requested the transfer.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">no</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            D synchronized calls allow this. Rust achieves this with std::sync::mpsc.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            9I. Signalling. It shall be possible to set a signal (without waiting), and to wait for a signal
            (without delay, if it is already set). Setting a signal, that is not already set, shall cause
            exactly one waiting path to continue.
        </td>
        <td class="yn">mostly?</td>
        <td class="yn">mostly?</td>
        <td class="yn">no</td>
        <td class="yn">mostly?</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            9J. Waiting. It shall be possible to wait for, determine, and act upon the first completed of
            several wait operations (including those used for data passing, signalling, and real time).
        </td>
        <td class="yn">mostly?</td>
        <td class="yn">mostly?</td>
        <td class="yn">no</td>
        <td class="yn">mostly?</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            10A. Exception Handling Facility. There shall be an exception handling mechanism for responding
            to unplanned error situations detected in declarations and statements during execution. The
            exception situations shall include errors detected by hardware, software errors detected during
            execution, error situations in built-in operations, and user defined exceptions. Exception
            identifiers shall have a scope. Exceptions should add to the execution time of programs only
            if they are raised.
        </td>
        <td class="yn">yes</td>
        <td class="yn">partial?</td>
        <td class="yn">partial?</td>
        <td class="yn">partial</td>
    </tr>
    <tr>
        <td colspan="4">
            Standard Pascal does not specify how to treat errors, whether with exceptions or otherwise. However
            later variations including FreePascal and Delphi support exceptions. Parasail attempts to check for
            all possible errors at compile time, however it is unclear from the reference manual how hardware
            problems are handled. Rust opts for using return value types to show errors rather than exceptions.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            10B. Error Situations. The errors detectable during execution shall include exceeding the
            specified range of an array subscript, exceeding the specified range of a variable, exceeding
            the implemented range of a variable, attempting to access an uninitialized variable, attempting
            to access a field of a variant that is not present, requesting a resource (such as stack or heap
            storage) when an insufficient quantity remains, and failing to satisfy a program specified assertion.
            [Note that some are very expensive to detect unless aided by special hardware, and consequently
            their detection will often be suppressed (see 10G).]
        </td>
        <td class="yn">partial?</td>
        <td class="yn">mostly</td>
        <td class="yn">partial</td>
        <td class="yn">partial?</td>
    </tr>
    <tr>
        <td colspan="4">
            Parasail is constructed to detect all of these mentioned errors, except the out of memory error, at
            compile time.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            10C. Raising Exceptions. There shall be an operation that raises an exception. Raising an
            exception shall cause transfer of control to the most local enclosing exception handler for
            that exception without completing execution of the current statement or declaration, but shall
            not of itself cause transfer out of a function, procedure, or process. Exceptions that are not
            handled within a function or procedure shall be raised again at the point of call in their callers.
            Exceptions that are not handled within a process shall terminate the process. Exceptions that can
            be raised by built-in operations shall be given in the language definition.
        </td>
        <td class="yn">yes</td>
        <td class="yn">partial</td>
        <td class="yn">partial</td>
        <td class="yn">partial</td>
    </tr>
    <tr>
        <td colspan="4">
            Standard Pascal does not specify how to handle errors, whether exceptions or otherwise, see 10A.
            It is unclear from the Parasail reference manual whether actual exceptions are used in the language,
            but similar functionality is achieved with compile time annotations. Rust opts for using return value
            types to show errors rather than exceptions. Various functions and macros are provided that more or
            less covers the same thing, but not in a way that satisfies this requirement.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            10D. Exception Handling. There shall be a control structure for discriminating among the
            exceptions that can occur in a specified statement sequence. The user may supply a single
            control path for all exceptions not otherwise mentioned in such a discrimination. It shall
            be possible to raise the exception that selected the current handler when exiting the handler.
        </td>
        <td class="yn">yes</td>
        <td class="yn">no?</td>
        <td class="yn">partial</td>
        <td class="yn">no</td>
    </tr>
    <tr>
        <td colspan="4">
            Standard Pascal does not specify how to handle errors, whether exceptions or otherwise, see 10A.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            10E. Order of Exceptions. The order in which exceptions in different parts of an expression
            are detected shall not be guaranteed by the language or by the translator.
        </td>
        <td class="yn">yes?</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            10F. Assertions. It shall be possible to include assertions in programs. If an assertion is
            false when encountered during execution, it shall raise an exception. It shall also be possible
            to include assertions, such as the expected frequency for selection of a conditional path, that
            cannot be verified. [Note that assertions can be used to aid optimization and maintenance.]
        </td>
        <td class="yn">mostly</td>
        <td class="yn">mostly</td>
        <td class="yn">no</td>
        <td class="yn">mostly</td>
    </tr>
    <tr>
        <td colspan="4">
            None? of these languages permit assertions of frequency.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            10G. Suppressing Exceptions. It shall be possible during translation to suppress individually
            the execution time detection of exceptions within a given scope. The language shall not guarantee
            the integrity of the values produced when a suppressed exception occurs. [Note that suppression
            of an exception is not an assertion that the corresponding error will not occur.]
        </td>
        <td class="yn">partial</td>
        <td class="yn">no</td>
        <td class="yn">no</td>
        <td class="yn">no</td>
    </tr>
    <tr>
        <td colspan="4">
            It is possible to statically disallow code from throwing exceptions in D, but that doesn't fulfil
            the same function as this requirement.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            11A. Data Representation. The language shall permit but not require programs to specify a single
            physical representation for the elements of a type. These specifications shall be separate from
            the logical descriptions. Physical representation shall include object representation of
            enumeration elements, order of fields, width of fields, presence of "don't care" fields,
            positions of word boundaries, and object machine addresses. In particular, the facility shall
            be sufficient to specify the physical representation of any record whose format is determined
            by considerations that are entirely external to the program, translator, and language. The
            language and its translators shall not guarantee any particular choice for those aspects of
            physical representation that are unspecified by the program. It shall be possible to specify
            the association of physical resources (e.g., interrupts) to program elements (e.g., exceptions
            or signals).
        </td>
        <td class="yn">partial?</td>
        <td class="yn">no?</td>
        <td class="yn">no</td>
        <td class="yn">partial</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            11C. Translation Time Facilities. To aid conditional compilation, it shall be possible to
            interrogate properties that are known during translation including characteristics of the
            object configuration, of function and procedure calling environments, and of actual parameters.
            For example, it shall be possible to determine whether the caller has suppressed a given
            exception, the callers optimization criteria, whether an actual parameter is a translation
            time expression, the type of actual generic parameters, and the values of constraints
            characterizing the subtype of actual parameters.
        </td>
        <td class="yn">partial</td>
        <td class="yn">partial?</td>
        <td class="yn">no</td>
        <td class="yn">partial</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            11D. Object System Configuration. The object system configuration must be explicitly specified
            in each separately translated unit. Such specifications must include the object machine model,
            the operating system if present, peripheral equipment, and the device configuration, and may
            include special hardware options and memory size. The translator will use such specifications
            when generating object code. [Note that programs that depend on the specific characteristics
            of the object machine, may be made more portable by enclosing those portions in branches of
            conditionals on the object machine configuration.]
        </td>
        <td class="yn">no?</td>
        <td class="yn">no?</td>
        <td class="yn">no</td>
        <td class="yn">no?</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            11E. Interface to Other Languages. There shall be a machine independent interface to other
            programming languages including assembly languages. Any program element that is referenced
            in both the source language program and foreign code must be identified in the interface. The
            source language of the foreign code must also be identified.
        </td>
        <td class="yn">yes</td>
        <td class="yn">no</td>
        <td class="yn">mostly</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
            D provides interfaces to C, C++ and assembly. Many Pascal implementations provide interfaces to
            C and assembly. Parasail provides no interfaces to other languages. Rust provides an interface to C
            and assembly.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            11F. Optimization. Programs may advise translators on the optimization criteria to be used in
            a scope. It shall be possible in programs to specify whether minimum translation costs or
            minimum execution costs are more important, and whether execution time or memory space is to
            be given preference. All such specifications shall be optional. Except for the amount of time
            and space required during execution, approximate values beyond the specified precision, the
            order in which exceptions are detected, and the occurrence of side effects within an expression,
            optimization shall not alter the semantics of correct programs, (e.g., the semantics of parameters
            will be unaffected by the choice between open and closed calls).
        </td>
        <td class="yn">partial?</td>
        <td class="yn">no?</td>
        <td class="yn">partial?</td>
        <td class="yn">partial?</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            12A. Library. There shall be an easily accessible library of generic definitions and separately
            translated units. All predefined definitions shall be in the library. Library entries may
            include those used as input-output packages, common pools of shared declarations, application
            oriented software packages, encapsulations, and machine configuration specifications. The
            library shall be structured to allow entries to be associated with particular applications,
            projects, and users.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            12B. Separately Translated Units. Separately translated units may be assembled into operational
            systems. It shall be possible for a separately translated unit to reference exported definitions
            of other units. All language imposed restrictions shall be enforced across such interfaces.
            Separate translation shall not change the semantics of a correct program.
        </td>
        <td class="yn">mostly?</td>
        <td class="yn">yes?</td>
        <td class="yn">yes?</td>
        <td class="yn">yes?</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            12D. Generic Definitions. Functions, procedures, types, and encapsulations may have generic
            parameters. Generic parameters shall be instantiated during translation and shall be interpreted
            in the context of the instantiation. An actual generic parameter may be any defined identifier
            (including those for variables, functions, procedures, processes, and types) or the value of any
            expression.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">partial</td>
        <td class="yn">mostly</td>
    </tr>
    <tr>
        <td colspan="4">
            Rust only accepts types as generic parameters. Standard Pascal does not support generics, but later
            Pascal derivatives such as Free Pascal and Delphi both do.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            13A. Defining Documents. The language shall have a complete and unambiguous defining document.
            It should be possible to predict the possible actions of any syntactically correct program
            from the language definition. The language documentation shall include the syntax, semantics,
            and appropriate examples of each built-in and predefined feature. A recommended set of
            translation diagnostic and warning messages shall be included in the language definition.
        </td>
        <td class="yn">mostly?</td>
        <td class="yn">mostly?</td>
        <td class="yn">yes</td>
        <td class="yn">partial</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            13B. Standards. There will be a standard definition of the language. Procedures will be
            established for standards control and for certification that translators meet the standard.
        </td>
        <td class="yn">no</td>
        <td class="yn">no</td>
        <td class="yn">yes</td>
        <td class="yn">no</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            13C. Completeness of Implementations. Translators shall implement the standard definition.
            Every translator shall be able to process any syntactically correct program. Every feature
            that is available to the user shall be defined in the standard, in an accessible library,
            or in the source program.
        </td>
        <td class="yn">mostly?</td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">mostly</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            13D. Translator Diagnostics. Translators shall be responsible for reporting errors that are
            detectable during translation and for optimizing object code. Translators shall be responsible
            for the integrity of object code in affected translation units when any separately translated
            unit is modified, and shall ensure that shared definitions have compatible representations in
            all translation units. Translators shall do full syntax and type checking, shall check that
            all language imposed restrictions are met, and should provide warnings where constructs will
            be dangerous or unusually expensive in execution and shall attempt to detect exceptions during
            translation. If the translator determines that a call on a routine will not terminate normally,
            the exception shall be reported as a translation error at the point of call.
        </td>
        <td class="yn">mostly?</td>
        <td class="yn">yes</td>
        <td class="yn">yes?</td>
        <td class="yn">yes?</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            13E. Translator Characteristics. Translators for the language will be written in the language
            and will be able to produce code for a variety of object machines. The machine independent
            parts of translators should be separate from code generators. Although it is desirable,
            translators need not be able to execute on every object machine. The internal characteristics
            of the translator (i.e., the translation method) shall not be specified by the language
            definition or standards.
        </td>
        <td class="yn">mostly</td>
        <td class="yn">mostly</td>
        <td class="yn">mostly</td>
        <td class="yn">mostly</td>
    </tr>
    <tr>
        <td colspan="4">
            Many, but not all, compilers are written in their own language. Parasail and Rust both have
            one compiler each, both written in their respective language.
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            13F. Restrictions on Translators. Translators shall fail to translate otherwise correct programs
            only when the program requires more resources during translation than are available on the host
            machine or when the program calls for resources that are unavailable in the specified object
            system configuration. Neither the language nor its translators shall impose arbitrary
            restrictions on language features. For example, they shall not impose restrictions on the
            number of array dimensions, on the number of identifiers, on the length of identifiers, or
            on the number of nested parentheses levels.
        </td>
        <td class="yn">yes</td>
        <td class="yn">yes</td>
        <td class="yn">yes?</td>
        <td class="yn">yes</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>

    <tr>
        <td rowspan="2">
            13G. Software Tools and Application Packages. The language should be designed to work in
            conjunction with a variety of useful software tools and application support packages. These
            will be developed as early as possible and will include editors, interpreters, diagnostic aids,
            program analyzers, documentation aids, testing aids, software maintenance tools, optimizers,
            and application libraries. There will be a consistent user interface for these tools. Where
            practical software tools and aids will be written in the language. Support for the design,
            implementation, distribution, and maintenance of translators, software tools and aids, and
            application libraries will be provided independently of the individual projects that use them.
        </td>
        <td class="yn">mostly</td>
        <td class="yn">partial</td>
        <td class="yn">yes</td>
        <td class="yn">partial</td>
    </tr>
    <tr>
        <td colspan="4">
        </td>
    </tr>
</table>

    </div>
</section>

{% endblock %}