From 14025d22ce3d66c9d235e57221ec4653e00f972c Mon Sep 17 00:00:00 2001 From: Jedidiah Barber Date: Fri, 26 Nov 2021 20:17:43 +1300 Subject: Switched to .xhtml extension, fixed some minor bugs --- project/templates/about.html | 72 - project/templates/about.xhtml | 72 + project/templates/adapad.html | 63 - project/templates/adapad.xhtml | 63 + project/templates/base.html | 36 - project/templates/base.xhtml | 36 + project/templates/base_math.html | 36 - project/templates/base_math.xhtml | 36 + project/templates/deckconv.html | 65 - project/templates/deckconv.xhtml | 65 + project/templates/fltkada.html | 112 -- project/templates/fltkada.xhtml | 112 ++ project/templates/grasp.html | 76 - project/templates/grasp.xhtml | 76 + project/templates/index.html | 28 - project/templates/index.xhtml | 28 + project/templates/integral.html | 241 --- project/templates/integral.xhtml | 241 +++ project/templates/links.html | 391 ----- project/templates/links.xhtml | 391 +++++ project/templates/packrat.html | 167 -- project/templates/packrat.xhtml | 167 ++ project/templates/sokoban.html | 38 - project/templates/sokoban.xhtml | 38 + project/templates/steelman.html | 2437 ------------------------------ project/templates/steelman.xhtml | 2437 ++++++++++++++++++++++++++++++ project/templates/stvcount.html | 304 ---- project/templates/stvcount.xhtml | 304 ++++ project/templates/sunset.html | 63 - project/templates/sunset.xhtml | 63 + project/templates/sydneyrail.html | 160 -- project/templates/sydneyrail.xhtml | 160 ++ project/templates/tags.html | 34 - project/templates/tags.xhtml | 34 + project/templates/tags/application.html | 32 - project/templates/tags/application.xhtml | 32 + project/templates/tags/binding.html | 32 - project/templates/tags/binding.xhtml | 32 + project/templates/tags/compsci.html | 32 - project/templates/tags/compsci.xhtml | 32 + project/templates/tags/copyright.html | 32 - project/templates/tags/copyright.xhtml | 32 + project/templates/tags/esoteric.html | 32 - project/templates/tags/esoteric.xhtml | 32 + project/templates/tags/language.html | 32 - project/templates/tags/language.xhtml | 32 + project/templates/tags/legal.html | 32 - project/templates/tags/legal.xhtml | 32 + project/templates/tags/library.html | 32 - project/templates/tags/library.xhtml | 32 + project/templates/tags/maps.html | 32 - project/templates/tags/maps.xhtml | 32 + project/templates/tags/mathematics.html | 32 - project/templates/tags/mathematics.xhtml | 32 + project/templates/tags/politics.html | 32 - project/templates/tags/politics.xhtml | 32 + project/templates/tags/programming.html | 32 - project/templates/tags/programming.xhtml | 32 + project/templates/tags/transport.html | 32 - project/templates/tags/transport.xhtml | 32 + project/templates/tags/videogames.html | 32 - project/templates/tags/videogames.xhtml | 32 + project/templates/thue2a.html | 105 -- project/templates/thue2a.xhtml | 105 ++ 64 files changed, 4876 insertions(+), 4876 deletions(-) delete mode 100644 project/templates/about.html create mode 100644 project/templates/about.xhtml delete mode 100644 project/templates/adapad.html create mode 100644 project/templates/adapad.xhtml delete mode 100644 project/templates/base.html create mode 100644 project/templates/base.xhtml delete mode 100644 project/templates/base_math.html create mode 100644 project/templates/base_math.xhtml delete mode 100644 project/templates/deckconv.html create mode 100644 project/templates/deckconv.xhtml delete mode 100644 project/templates/fltkada.html create mode 100644 project/templates/fltkada.xhtml delete mode 100644 project/templates/grasp.html create mode 100644 project/templates/grasp.xhtml delete mode 100644 project/templates/index.html create mode 100644 project/templates/index.xhtml delete mode 100644 project/templates/integral.html create mode 100644 project/templates/integral.xhtml delete mode 100644 project/templates/links.html create mode 100644 project/templates/links.xhtml delete mode 100644 project/templates/packrat.html create mode 100644 project/templates/packrat.xhtml delete mode 100644 project/templates/sokoban.html create mode 100644 project/templates/sokoban.xhtml delete mode 100644 project/templates/steelman.html create mode 100644 project/templates/steelman.xhtml delete mode 100644 project/templates/stvcount.html create mode 100644 project/templates/stvcount.xhtml delete mode 100644 project/templates/sunset.html create mode 100644 project/templates/sunset.xhtml delete mode 100644 project/templates/sydneyrail.html create mode 100644 project/templates/sydneyrail.xhtml delete mode 100644 project/templates/tags.html create mode 100644 project/templates/tags.xhtml delete mode 100644 project/templates/tags/application.html create mode 100644 project/templates/tags/application.xhtml delete mode 100644 project/templates/tags/binding.html create mode 100644 project/templates/tags/binding.xhtml delete mode 100644 project/templates/tags/compsci.html create mode 100644 project/templates/tags/compsci.xhtml delete mode 100644 project/templates/tags/copyright.html create mode 100644 project/templates/tags/copyright.xhtml delete mode 100644 project/templates/tags/esoteric.html create mode 100644 project/templates/tags/esoteric.xhtml delete mode 100644 project/templates/tags/language.html create mode 100644 project/templates/tags/language.xhtml delete mode 100644 project/templates/tags/legal.html create mode 100644 project/templates/tags/legal.xhtml delete mode 100644 project/templates/tags/library.html create mode 100644 project/templates/tags/library.xhtml delete mode 100644 project/templates/tags/maps.html create mode 100644 project/templates/tags/maps.xhtml delete mode 100644 project/templates/tags/mathematics.html create mode 100644 project/templates/tags/mathematics.xhtml delete mode 100644 project/templates/tags/politics.html create mode 100644 project/templates/tags/politics.xhtml delete mode 100644 project/templates/tags/programming.html create mode 100644 project/templates/tags/programming.xhtml delete mode 100644 project/templates/tags/transport.html create mode 100644 project/templates/tags/transport.xhtml delete mode 100644 project/templates/tags/videogames.html create mode 100644 project/templates/tags/videogames.xhtml delete mode 100644 project/templates/thue2a.html create mode 100644 project/templates/thue2a.xhtml (limited to 'project/templates') diff --git a/project/templates/about.html b/project/templates/about.html deleted file mode 100644 index 723c530..0000000 --- a/project/templates/about.html +++ /dev/null @@ -1,72 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}About{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

About Me

- -

Does the massive gap between what is known and what is mainstream bother anyone else? It bothers -me. The field of computing is littered with ideas that are well researched, have working prototypes, -and would be very useful, yet ended up abandoned decades ago for no apparent reason. I expect other -fields are probably similar. One of my goals in life is to reduce this gap between what's known and -what's actually used. Mainly in software development, because that's what I'm most familiar with. -

- -

So this website is primarily about hosting and talking about programming projects. But also -expect electronics, civics, foreign languages, food, videogames... basically anything catching my -interest about which I can say something data driven or otherwise interesting.

- -

Details of where I grew up and whatnot are unimportant, but it is worth noting that in the first -half of 2021 I moved my place of residence from NSW, Australia to the South Island of New Zealand -due to extreme corruption and abuses of power going on in the Australian Federal Government. This -caused this website to go offline for a few months since it was being hosted on a home server at the -time, but it has since been moved to a VPS so that's all fixed now.

- -

Qualifications

- - - -

In 2012 I almost completed an extra honours year in computer science, before finding out that I'm -really not cut out for research. My mindset is too focused on solving practical problems and my -talent for prose is comparatively not so great. -

- -

Contact

- - - - - - - - - - -
Email:contact@REMOVETHISjedbarber.id.au
IRC:jedb on irc.libera.chat
- -

Technical Details

- -

This website is best viewed with any browser compliant with XHTML 1.1, MathML 2.0, and CSS 3. If -your browser cannot handle those standards, tough. Get a better web browser.

- -

This website will never require any form of Javascript for optimal viewing. The use of -Turing-complete client side scripting in web browsers is an abomination.

-{% endblock -%} - - diff --git a/project/templates/about.xhtml b/project/templates/about.xhtml new file mode 100644 index 0000000..8eef5e4 --- /dev/null +++ b/project/templates/about.xhtml @@ -0,0 +1,72 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}About{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

About Me

+ +

Does the massive gap between what is known and what is mainstream bother anyone else? It bothers +me. The field of computing is littered with ideas that are well researched, have working prototypes, +and would be very useful, yet ended up abandoned decades ago for no apparent reason. I expect other +fields are probably similar. One of my goals in life is to reduce this gap between what's known and +what's actually used. Mainly in software development, because that's what I'm most familiar with. +

+ +

So this website is primarily about hosting and talking about programming projects. But also +expect electronics, civics, foreign languages, food, videogames... basically anything catching my +interest about which I can say something data driven or otherwise interesting.

+ +

Details of where I grew up and whatnot are unimportant, but it is worth noting that in the first +half of 2021 I moved my place of residence from NSW, Australia to the South Island of New Zealand +due to extreme corruption and abuses of power going on in the Australian Federal Government. This +caused this website to go offline for a few months since it was being hosted on a home server at the +time, but it has since been moved to a VPS so that's all fixed now.

+ +

Qualifications

+ + + +

In 2012 I almost completed an extra honours year in computer science, before finding out that I'm +really not cut out for research. My mindset is too focused on solving practical problems and my +talent for prose is comparatively not so great. +

+ +

Contact

+ + + + + + + + + + +
Email:contact@REMOVETHISjedbarber.id.au
IRC:jedb on irc.libera.chat
+ +

Technical Details

+ +

This website is best viewed with any browser compliant with XHTML 1.1, MathML 2.0, and CSS 3. If +your browser cannot handle those standards, tough. Get a better web browser.

+ +

This website will never require any form of Javascript for optimal viewing. The use of +Turing-complete client side scripting in web browsers is an abomination.

+{% endblock -%} + + diff --git a/project/templates/adapad.html b/project/templates/adapad.html deleted file mode 100644 index 9982aca..0000000 --- a/project/templates/adapad.html +++ /dev/null @@ -1,63 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Adapad{%- endblock -%} - - - -{%- block content %} -

Adapad

- -

Git repository: Link

- -
8/5/2017
- -

The Ada binding for FLTK has now been moved to its own -repository. Installing it is required to build and use Adapad, naturally. Both repositories are -set up to use the GNAT Project Manager build tools to handle all that, with any further specific -details in each project's readme.

- - -
2/1/2017
- -

I have a soft spot for the Ada programming -language. Strong typing, built in concurrency, readable syntax, systems support, real-time -support, a general culture of correctness and emphasising reliability... what's not to like? I also -have a bit of an interest in FLTK, -being one of the more prominent tiny graphics toolkits around. Adapad is a notepad clone born as a -side project from efforts to create an Ada binding for FLTK.

- -
- A screenshot of Adapad -
Adapad in action
-
- -

It was modeled after Leafpad, -and the feature list is similar, currently comprising:

- - - -

This is approximately what I was going for. However, at the current time of writing it is still -considered to be at v0.8 due to a few minor issues, such as the horizontal scrollbar appearing even -when only vertical scroll is possible. That may be an FLTK issue, but that's not an excuse from an -end user perspective.

- -

The FLTK/Ada binding currently occupies the same repository as Adapad, but will be moved to its -own as work progresses.

-{% endblock -%} - - diff --git a/project/templates/adapad.xhtml b/project/templates/adapad.xhtml new file mode 100644 index 0000000..542feaf --- /dev/null +++ b/project/templates/adapad.xhtml @@ -0,0 +1,63 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Adapad{%- endblock -%} + + + +{%- block content %} +

Adapad

+ +

Git repository: Link

+ +
8/5/2017
+ +

The Ada binding for FLTK has now been moved to its own +repository. Installing it is required to build and use Adapad, naturally. Both repositories are +set up to use the GNAT Project Manager build tools to handle all that, with any further specific +details in each project's readme.

+ + +
2/1/2017
+ +

I have a soft spot for the Ada programming +language. Strong typing, built in concurrency, readable syntax, systems support, real-time +support, a general culture of correctness and emphasising reliability... what's not to like? I also +have a bit of an interest in FLTK, +being one of the more prominent tiny graphics toolkits around. Adapad is a notepad clone born as a +side project from efforts to create an Ada binding for FLTK.

+ +
+ A screenshot of Adapad +
Adapad in action
+
+ +

It was modeled after Leafpad, +and the feature list is similar, currently comprising:

+ + + +

This is approximately what I was going for. However, at the current time of writing it is still +considered to be at v0.8 due to a few minor issues, such as the horizontal scrollbar appearing even +when only vertical scroll is possible. That may be an FLTK issue, but that's not an excuse from an +end user perspective.

+ +

The FLTK/Ada binding currently occupies the same repository as Adapad, but will be moved to its +own as work progresses.

+{% endblock -%} + + diff --git a/project/templates/base.html b/project/templates/base.html deleted file mode 100644 index 7282f57..0000000 --- a/project/templates/base.html +++ /dev/null @@ -1,36 +0,0 @@ - - - - - - {% block title %}{% endblock %} - - -{%- block style -%} -{%- endblock -%} - - -
-

Jedidiah Barber's Personal Site

-
-
- -
-
-
-{% block content -%} -{%- endblock %} -
-
-
- - - diff --git a/project/templates/base.xhtml b/project/templates/base.xhtml new file mode 100644 index 0000000..a05e26b --- /dev/null +++ b/project/templates/base.xhtml @@ -0,0 +1,36 @@ + + + + + + {% block title %}{% endblock %} + + +{%- block style -%} +{%- endblock -%} + + +
+

Jedidiah Barber's Personal Site

+
+
+ +
+
+
+{% block content -%} +{%- endblock %} +
+
+
+ + + diff --git a/project/templates/base_math.html b/project/templates/base_math.html deleted file mode 100644 index 025968c..0000000 --- a/project/templates/base_math.html +++ /dev/null @@ -1,36 +0,0 @@ - - - - - - {% block title %}{% endblock %} - - -{%- block style -%} -{%- endblock -%} - - -
-

Jedidiah Barber's Personal Site

-
-
- -
-
-
-{% block content -%} -{%- endblock %} -
-
-
- - - diff --git a/project/templates/base_math.xhtml b/project/templates/base_math.xhtml new file mode 100644 index 0000000..3b5be69 --- /dev/null +++ b/project/templates/base_math.xhtml @@ -0,0 +1,36 @@ + + + + + + {% block title %}{% endblock %} + + +{%- block style -%} +{%- endblock -%} + + +
+

Jedidiah Barber's Personal Site

+
+
+ +
+
+
+{% block content -%} +{%- endblock %} +
+
+
+ + + diff --git a/project/templates/deckconv.html b/project/templates/deckconv.html deleted file mode 100644 index 4103518..0000000 --- a/project/templates/deckconv.html +++ /dev/null @@ -1,65 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Flashcard Deck Converter{%- endblock -%} - - - -{%- block content %} -

Flashcard Deck Converter

- -

Git repository: Link

- - -
11/11/2021
- -

Anki is a sophisticated spaced repetition flashcard program. It also has a codebase going on 15 -years old made of Python and Rust, dependencies that make heavy use of Go, and a - -convoluted deck format, all to produce a desktop program 100-140MB in size depending on -operating system. In short? It's a mess. But since it has been around for so long and is currently -the most used open source flashcard program it is also the one with the most decks people have made -for it.

- -

The nearest competitor to Anki in my assessment is Fresh Memory. It is a much more compact and -tidy project written in C++ using Qt with similar functionality for spaced reptition using -arbitrarily sided flashcards. On the list of what's available the only other open source options are Mnemosyne, -another massive mess of Python, or OpenCards, which uses Microsoft Powerpoint of all things for the -deck format. Unfortunately Fresh Memory was abandoned shortly after it was open sourced and has a -whole host of minor issues that need working on. I'll get around to doing that eventually.

- -

In the meantime, here's a utility that converts Anki .apkg decks to Fresh Memory .fmd decks. -Oh, and it can also output to comma separated value format too if you find that more useful. Due to -differences between formats some information does not carry over very well, but for most decks it -should still perform adequately.

- -
- A screenshot of the command line deck converter -
Command line utility
-
- -

Aside from the command line there's also a simple graphical interface put together using FLTK. -Not the most pretty, but it works.

- -
- A screenshot of the graphical interface to the deck converter -
Graphical utility
-
- -

Anyone trying to compile this utility or otherwise taking a quick peek at the code or readme may -note there are quite a few dependencies involved. This is due to Anki's aforementioned convoluted -deck format. Digging down through layers of JSON inside an SQLite database inside a zipfile is a -little bothersome. Dealing with Fresh Memory's current XML based deck format is a walk in the park -by comparison, even if it is more unwieldy due to any deck with media not being all one file.

-{% endblock -%} - - diff --git a/project/templates/deckconv.xhtml b/project/templates/deckconv.xhtml new file mode 100644 index 0000000..ee8abd5 --- /dev/null +++ b/project/templates/deckconv.xhtml @@ -0,0 +1,65 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Flashcard Deck Converter{%- endblock -%} + + + +{%- block content %} +

Flashcard Deck Converter

+ +

Git repository: Link

+ + +
11/11/2021
+ +

Anki is a sophisticated spaced repetition flashcard program. It also has a codebase going on 15 +years old made of Python and Rust, dependencies that make heavy use of Go, and a + +convoluted deck format, all to produce a desktop program 100-140MB in size depending on +operating system. In short? It's a mess. But since it has been around for so long and is currently +the most used open source flashcard program it is also the one with the most decks people have made +for it.

+ +

The nearest competitor to Anki in my assessment is Fresh Memory. It is a much more compact and +tidy project written in C++ using Qt with similar functionality for spaced reptition using +arbitrarily sided flashcards. On the list of what's available the only other open source options are Mnemosyne, +another massive mess of Python, or OpenCards, which uses Microsoft Powerpoint of all things for the +deck format. Unfortunately Fresh Memory was abandoned shortly after it was open sourced and has a +whole host of minor issues that need working on. I'll get around to doing that eventually.

+ +

In the meantime, here's a utility that converts Anki .apkg decks to Fresh Memory .fmd decks. +Oh, and it can also output to comma separated value format too if you find that more useful. Due to +differences between formats some information does not carry over very well, but for most decks it +should still perform adequately.

+ +
+ A screenshot of the command line deck converter +
Command line utility
+
+ +

Aside from the command line there's also a simple graphical interface put together using FLTK. +Not the most pretty, but it works.

+ +
+ A screenshot of the graphical interface to the deck converter +
Graphical utility
+
+ +

Anyone trying to compile this utility or otherwise taking a quick peek at the code or readme may +note there are quite a few dependencies involved. This is due to Anki's aforementioned convoluted +deck format. Digging down through layers of JSON inside an SQLite database inside a zipfile is a +little bothersome. Dealing with Fresh Memory's current XML based deck format is a walk in the park +by comparison, even if it is more unwieldy due to any deck with media not being all one file.

+{% endblock -%} + + diff --git a/project/templates/fltkada.html b/project/templates/fltkada.html deleted file mode 100644 index 8bb477f..0000000 --- a/project/templates/fltkada.html +++ /dev/null @@ -1,112 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}FLTK Ada{%- endblock -%} - - - -{%- block content %} -

FLTK Ada Binding

- -

Git repository: Link
-Estimated status: 80% complete

- - -
9/11/2021
- -

A few noteworthy bugfixes have been applied to the binding.

- -

First, unbeknownst to me the Fl_Widget constructor doesn't copy the given label string inside -FLTK and merely stores a pointer. This meant that declaring several Widgets in a row each with their -own different label could have unexpected and erratic results. Easily fixed by ensuring the binding -constructor also calls copy_label() afterwards.

- -

And second, somehow I had made an oversight with the type assigned to Color, using a signed -Integer when it really needed an unsigned modular type with 32 bits of range. Again, easily fixed -but even more annoying since it was my fault to begin with.

- -

I'm sure the other guy aside from me who takes an interest in this binding will be happy about -these. You know who you are.

- - -
21/5/2018
- -

This binding is now complete enough for most purposes. It certainly took more effort than -expected, in part due to underestimation of how much needed binding. The vast majority of useful -classes are now usable in Ada, with a few exceptions such as the Fl_Browser, Fl_Help_View, Fl_Table, -and Fl_Tree widgets.

- -

Noteworthy features and modifications include:

- - -

A mapping of what C++ headers and methods correspond to what Ada packages, functions, and -procedures is included. Also, the below "Hello world" code sample has been modified to work with the -updated binding.

- - -
25/6/2017
- -

FLTK, or by its full name the Fast Light Toolkit -, is a graphical widget toolkit noteworthy for being so lightweight that it is commonly -statically linked. Projects that make use of it include the Dillo web browser, the -FLWM X window manager, and the -Equinox Desktop Environment. There are bindings for it in several languages, including Python, -Perl and Ruby, but not Ada. Until now!

- -

This is a spinoff from Adapad, and so despite not yet being complete it can be at least -guaranteed to be enough to write a text editor. It's a thick, loosely coupled binding, accomplished -by first exporting the interface to C, then importing that to Ada. Attempted usage of the internal C -interface as a binding on its own is not supported.

- -

A typical FLTK Hello World program in Ada:

-
- -with - FLTK.Widgets.Groups.Windows, - FLTK.Widgets.Boxes; - -function Hello_World return Integer is - - My_Win : FLTK.Widgets.Groups.Windows.Window := - FLTK.Widgets.Groups.Windows.Forge.Create (100, 100, 200, 200, "Untitled"); - - My_Box : FLTK.Widgets.Boxes.Box := - FLTK.Widgets.Boxes.Forge.Create (50, 50, 100, 100, "Hello, World!"); - -begin - - My_Win.Add (My_Box); - My_Win.Show; - - return FLTK.Run; - -end Hello_World; - -
- -

Aside from reworking the types to better fit the strongly typed philosophy of Ada, the entire -library has been structured to avoid explicit heap usage. As you can see from the above example, the -intended use is to declare FLTK objects on the stack. Allocation and deallocation of the C++ -internals is handled automatically.

- -

A few other minor changes were involved, such as requiring widgets to be explicitly added to a -group rather than implicitly being added to the last group not yet ended. At the moment the package -specifications should provide sufficient information to allow programmers to work with the library. -

-{% endblock -%} - - diff --git a/project/templates/fltkada.xhtml b/project/templates/fltkada.xhtml new file mode 100644 index 0000000..f68ea27 --- /dev/null +++ b/project/templates/fltkada.xhtml @@ -0,0 +1,112 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}FLTK Ada{%- endblock -%} + + + +{%- block content %} +

FLTK Ada Binding

+ +

Git repository: Link
+Estimated status: 80% complete

+ + +
9/11/2021
+ +

A few noteworthy bugfixes have been applied to the binding.

+ +

First, unbeknownst to me the Fl_Widget constructor doesn't copy the given label string inside +FLTK and merely stores a pointer. This meant that declaring several Widgets in a row each with their +own different label could have unexpected and erratic results. Easily fixed by ensuring the binding +constructor also calls copy_label() afterwards.

+ +

And second, somehow I had made an oversight with the type assigned to Color, using a signed +Integer when it really needed an unsigned modular type with 32 bits of range. Again, easily fixed +but even more annoying since it was my fault to begin with.

+ +

I'm sure the other guy aside from me who takes an interest in this binding will be happy about +these. You know who you are.

+ + +
21/5/2018
+ +

This binding is now complete enough for most purposes. It certainly took more effort than +expected, in part due to underestimation of how much needed binding. The vast majority of useful +classes are now usable in Ada, with a few exceptions such as the Fl_Browser, Fl_Help_View, Fl_Table, +and Fl_Tree widgets.

+ +

Noteworthy features and modifications include:

+ + +

A mapping of what C++ headers and methods correspond to what Ada packages, functions, and +procedures is included. Also, the below "Hello world" code sample has been modified to work with the +updated binding.

+ + +
25/6/2017
+ +

FLTK, or by its full name the Fast Light Toolkit +, is a graphical widget toolkit noteworthy for being so lightweight that it is commonly +statically linked. Projects that make use of it include the Dillo web browser, the +FLWM X window manager, and the +Equinox Desktop Environment. There are bindings for it in several languages, including Python, +Perl and Ruby, but not Ada. Until now!

+ +

This is a spinoff from Adapad, and so despite not yet being complete it can be at least +guaranteed to be enough to write a text editor. It's a thick, loosely coupled binding, accomplished +by first exporting the interface to C, then importing that to Ada. Attempted usage of the internal C +interface as a binding on its own is not supported.

+ +

A typical FLTK Hello World program in Ada:

+
+ +with + FLTK.Widgets.Groups.Windows, + FLTK.Widgets.Boxes; + +function Hello_World return Integer is + + My_Win : FLTK.Widgets.Groups.Windows.Window := + FLTK.Widgets.Groups.Windows.Forge.Create (100, 100, 200, 200, "Untitled"); + + My_Box : FLTK.Widgets.Boxes.Box := + FLTK.Widgets.Boxes.Forge.Create (50, 50, 100, 100, "Hello, World!"); + +begin + + My_Win.Add (My_Box); + My_Win.Show; + + return FLTK.Run; + +end Hello_World; + +
+ +

Aside from reworking the types to better fit the strongly typed philosophy of Ada, the entire +library has been structured to avoid explicit heap usage. As you can see from the above example, the +intended use is to declare FLTK objects on the stack. Allocation and deallocation of the C++ +internals is handled automatically.

+ +

A few other minor changes were involved, such as requiring widgets to be explicitly added to a +group rather than implicitly being added to the last group not yet ended. At the moment the package +specifications should provide sufficient information to allow programmers to work with the library. +

+{% endblock -%} + + diff --git a/project/templates/grasp.html b/project/templates/grasp.html deleted file mode 100644 index a213c02..0000000 --- a/project/templates/grasp.html +++ /dev/null @@ -1,76 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Grasp Interpreter{%- endblock -%} - - - -{%- block content %} -

Grasp Interpreter

- -

Git repository: Link

- -
1/1/2017
- -

Like Lisp, the esoteric programming language Grasp is a homoiconic language that exclusively uses a single datatype. Except -instead of lists, it uses directed graphs.

- -

A Grasp program is initialised with instruction pointers to those nodes in the graph that have -a "name" edge to a node with the value "grasp:main". The nodes at each instruction pointer are -evaluated and the pointer then updated by following an available "next" edge. This continues until -all instruction pointers have no more "next" edges to follow.

- -
- Hello World in Grasp -
Hello World in Grasp
-
- -

In the current -specification, the actions that can be performed are:

- - - -

The execution of a node may be skipped by having "cond" edges pointing to either zero values or -non-numeric values. Also, due to the way instruction pointers update and the way several -instructions are defined, there is a measure of non-determinism that can be introduced depending on -what edges are available.

- -

The language seemed like an interesting enough idea, but unfortunately nobody had done anything -with it, and there was only a specification. This has now been fixed. The interpreter currently -uses a subset of the DOT graph -description language for the file format, to enable a text format as well as relatively easy -conversion to a graph image.

- -

The above example is recorded as follows:

-
- -digraph { - 1 [label="puts"] - 2 [label="grasp:main"] - 3 [label="Hello world!"] - - 1 -> 2 [label="name"] - 1 -> 3 [label="in"] -} - -
- -

If a format that more readily converts to a comprehensible graph image is found, a parser for it -may be added.

-{% endblock -%} - - diff --git a/project/templates/grasp.xhtml b/project/templates/grasp.xhtml new file mode 100644 index 0000000..5afc4b7 --- /dev/null +++ b/project/templates/grasp.xhtml @@ -0,0 +1,76 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Grasp Interpreter{%- endblock -%} + + + +{%- block content %} +

Grasp Interpreter

+ +

Git repository: Link

+ +
1/1/2017
+ +

Like Lisp, the esoteric programming language Grasp is a homoiconic language that exclusively uses a single datatype. Except +instead of lists, it uses directed graphs.

+ +

A Grasp program is initialised with instruction pointers to those nodes in the graph that have +a "name" edge to a node with the value "grasp:main". The nodes at each instruction pointer are +evaluated and the pointer then updated by following an available "next" edge. This continues until +all instruction pointers have no more "next" edges to follow.

+ +
+ Hello World in Grasp +
Hello World in Grasp
+
+ +

In the current +specification, the actions that can be performed are:

+ + + +

The execution of a node may be skipped by having "cond" edges pointing to either zero values or +non-numeric values. Also, due to the way instruction pointers update and the way several +instructions are defined, there is a measure of non-determinism that can be introduced depending on +what edges are available.

+ +

The language seemed like an interesting enough idea, but unfortunately nobody had done anything +with it, and there was only a specification. This has now been fixed. The interpreter currently +uses a subset of the DOT graph +description language for the file format, to enable a text format as well as relatively easy +conversion to a graph image.

+ +

The above example is recorded as follows:

+
+ +digraph { + 1 [label="puts"] + 2 [label="grasp:main"] + 3 [label="Hello world!"] + + 1 -> 2 [label="name"] + 1 -> 3 [label="in"] +} + +
+ +

If a format that more readily converts to a comprehensible graph image is found, a parser for it +may be added.

+{% endblock -%} + + diff --git a/project/templates/index.html b/project/templates/index.html deleted file mode 100644 index c0a1ed7..0000000 --- a/project/templates/index.html +++ /dev/null @@ -1,28 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Jedidiah Barber's Personal Site{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} - -{% endblock -%} - - diff --git a/project/templates/index.xhtml b/project/templates/index.xhtml new file mode 100644 index 0000000..1026136 --- /dev/null +++ b/project/templates/index.xhtml @@ -0,0 +1,28 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Jedidiah Barber's Personal Site{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} + +{% endblock -%} + + diff --git a/project/templates/integral.html b/project/templates/integral.html deleted file mode 100644 index 364fe84..0000000 --- a/project/templates/integral.html +++ /dev/null @@ -1,241 +0,0 @@ - -{%- extends "base_math.html" -%} - - - -{%- block title -%}Area Under the Curve of a Complex Integral{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

Area Under the Curve of a Complex Integral

- -

Scripts used to generate graphs: Link

- -
29/12/2018
- -

A definite integral can be represented on the xy-plane as the signed area bounded by the curve of -the function f(x), the x-axis, and the limits of integration a and b. But it's not immediately clear -how this definition applies for complex valued functions.

- -

Consider the following example:

- -
- - - - ∫ - 0 - 1 - - - - ( - -1 - ) - - x - - dx - - -
- -

If the function is graphed on the xy-plane, the real valued outputs are sparse. Yet an elementary -antiderivative exists and the definite integral is well defined.

- -
- Real values only plot of minus one raised to the x power -
Figure 1 - Real values only
-
- -

In order to plot a meaningful graph that can be used to potentially calculate the integral as a -signed area, some cues are taken from Philip Lloyd's work on -Phantom Graphs. In that work, an -additional z-axis is used to extend the x-axis into a complex xz-plane, allowing complex inputs to -be graphed. For the function considered here, the z-axis is instead used to extend the y-axis into a -complex yz-plane to allow graphing of complex outputs instead.

- -

Upon doing so, the following helical graph is obtained:

- -
- Complete three dimensional graph of all values of minux one raised to the x power -
Figure 2 - Full graph
-
- -

The curve is continuous and spirals around the x-axis, intersecting with the real xy-plane at the -points plotted in the initial graph of Figure 1. However it is still not clear how to represent the -area under the curve.

- -

Observing that complex numbers in cartesian form are composed of a real part and an imaginary -part, it is possible to decompose the function into real and imaginary components. These are easy to -obtain by rotating the graph above to view the real and imaginary parts as flat planes.

- - - - - - -
-
- Graph of the real component of minus one raised to the power of x -
Figure 3 - Real component
-
- 		-
- Graph of the imaginary component of minus one raised to the power of x -
Figure 4 - Imaginary component
-
-
- -

From this it can be seen that the function is a combination of a real valued cosine and an -imaginary valued sine. With the limits of integration under consideration, the real values disappear -and we are left with the following:

- -
- - - - - - - - - - - - - - - - - - - - -
- - - - ∫ - 0 - 1 - - - - ( - -1 - ) - - x - - dx - - -
= - - - i - - ∫ - 0 - 1 - - sin - - ( - π - ⁢ - x - ) - - dx - - -
= - - - - - - i - π - - - - - cos - - ( - π - ⁢ - x - ) - - - - 0 - 1 - - - -
= - - - - - - i - π - - - ( - -1 - - - 1 - ) - - - -
= - - - - - 2 - i - - π - - - -
-
- -

This agrees with the answer obtained by ordinary evaluation of the integral without considering -the graph, so the informal area under the curve definition still works. Considering the area under -the curve using polar coordinates also works, but requires evaluating a less than pleasant infinite -sum and so won't be considered here.

- -

The next interesting question is how this relates to the surface area of a - -right helicoid.

-{% endblock -%} - - diff --git a/project/templates/integral.xhtml b/project/templates/integral.xhtml new file mode 100644 index 0000000..8f2f33a --- /dev/null +++ b/project/templates/integral.xhtml @@ -0,0 +1,241 @@ + +{%- extends "base_math.xhtml" -%} + + + +{%- block title -%}Area Under the Curve of a Complex Integral{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

Area Under the Curve of a Complex Integral

+ +

Scripts used to generate graphs: Link

+ +
29/12/2018
+ +

A definite integral can be represented on the xy-plane as the signed area bounded by the curve of +the function f(x), the x-axis, and the limits of integration a and b. But it's not immediately clear +how this definition applies for complex valued functions.

+ +

Consider the following example:

+ +
+ + + + ∫ + 0 + 1 + + + + ( + -1 + ) + + x + + dx + + +
+ +

If the function is graphed on the xy-plane, the real valued outputs are sparse. Yet an elementary +antiderivative exists and the definite integral is well defined.

+ +
+ Real values only plot of minus one raised to the x power +
Figure 1 - Real values only
+
+ +

In order to plot a meaningful graph that can be used to potentially calculate the integral as a +signed area, some cues are taken from Philip Lloyd's work on +Phantom Graphs. In that work, an +additional z-axis is used to extend the x-axis into a complex xz-plane, allowing complex inputs to +be graphed. For the function considered here, the z-axis is instead used to extend the y-axis into a +complex yz-plane to allow graphing of complex outputs instead.

+ +

Upon doing so, the following helical graph is obtained:

+ +
+ Complete three dimensional graph of all values of minux one raised to the x power +
Figure 2 - Full graph
+
+ +

The curve is continuous and spirals around the x-axis, intersecting with the real xy-plane at the +points plotted in the initial graph of Figure 1. However it is still not clear how to represent the +area under the curve.

+ +

Observing that complex numbers in cartesian form are composed of a real part and an imaginary +part, it is possible to decompose the function into real and imaginary components. These are easy to +obtain by rotating the graph above to view the real and imaginary parts as flat planes.

+ + + + + + +
+
+ Graph of the real component of minus one raised to the power of x +
Figure 3 - Real component
+
+ 		+
+ Graph of the imaginary component of minus one raised to the power of x +
Figure 4 - Imaginary component
+
+
+ +

From this it can be seen that the function is a combination of a real valued cosine and an +imaginary valued sine. With the limits of integration under consideration, the real values disappear +and we are left with the following:

+ +
+ + + + + + + + + + + + + + + + + + + + +
+ + + + ∫ + 0 + 1 + + + + ( + -1 + ) + + x + + dx + + +
= + + + i + + ∫ + 0 + 1 + + sin + + ( + π + ⁢ + x + ) + + dx + + +
= + + + - + + i + π + + + + + cos + + ( + π + ⁢ + x + ) + + + + 0 + 1 + + + +
= + + + - + + i + π + + + ( + -1 + - + 1 + ) + + + +
= + + + + + 2 + i + + π + + + +
+
+ +

This agrees with the answer obtained by ordinary evaluation of the integral without considering +the graph, so the informal area under the curve definition still works. Considering the area under +the curve using polar coordinates also works, but requires evaluating a less than pleasant infinite +sum and so won't be considered here.

+ +

The next interesting question is how this relates to the surface area of a + +right helicoid.

+{% endblock -%} + + diff --git a/project/templates/links.html b/project/templates/links.html deleted file mode 100644 index 3b4d4bf..0000000 --- a/project/templates/links.html +++ /dev/null @@ -1,391 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Links{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

Links

- -

These are some of the websites that found their way into my bookmarks over the years. Quite a -few years, since some of these require the Wayback Machine to view now. Posted because if I find -these pages interesting, chances are someone else might too. Note that this list is not anywhere -near exhaustive.
-
-Please do not send me suggestions for websites to put here. While I am sure you mean well, I much -prefer to discover these things for myself.

- -
-
-
-
Blogs
- - -
Books
- - -
Computer Hardware
- - -
DIY
- - -
Electronics
- - -
Fitness and Cycling
- - -
Food
- - -
Foreign Languages
- - -
Gaming
- - -
General Computing
- -
-
-
-
-
Math and Logic
- - -
Operating Systems
- - -
Other
- - -
Politics and Law
- - -
Programming
- - -
Science
- - -
Travel and Transportation
- -
-
-
-{% endblock -%} - - diff --git a/project/templates/links.xhtml b/project/templates/links.xhtml new file mode 100644 index 0000000..991810b --- /dev/null +++ b/project/templates/links.xhtml @@ -0,0 +1,391 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Links{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

Links

+ +

These are some of the websites that found their way into my bookmarks over the years. Quite a +few years, since some of these require the Wayback Machine to view now. Posted because if I find +these pages interesting, chances are someone else might too. Note that this list is not anywhere +near exhaustive.
+
+Please do not send me suggestions for websites to put here. While I am sure you mean well, I much +prefer to discover these things for myself.

+ +
+
+
+
Blogs
+ + +
Books
+ + +
Computer Hardware
+ + +
DIY
+ + +
Electronics
+ + +
Fitness and Cycling
+ + +
Food
+ + +
Foreign Languages
+ + +
Gaming
+ + +
General Computing
+ +
+
+
+
+
Math and Logic
+ + +
Operating Systems
+ + +
Other
+ + +
Politics and Law
+ + +
Programming
+ + +
Science
+ + +
Travel and Transportation
+ +
+
+
+{% endblock -%} + + diff --git a/project/templates/packrat.html b/project/templates/packrat.html deleted file mode 100644 index 4ae1c3e..0000000 --- a/project/templates/packrat.html +++ /dev/null @@ -1,167 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Packrat Parser Combinator Library{%- endblock -%} - - - -{%- block content %} -

Packrat Parser Combinator Library

- -

Git repository: Link
-Paper this was based on: Link

- -
2/2/2021
- - -
Overview
- -

Parser combinators are what you end up with when you start factoring out common pieces of -functionality from -recursive descent parsing. They are higher order functions that can be combined in modular ways -to create a desired parser.

- -

However they also inherit the drawbacks of recursive descent parsing, and in particular recursive -descent parsing with backtracking. If the grammar that the parser is designed to accept contains -left recursion then the parser will loop infinitely. If the grammar is ambiguous then only one -result will be obtained. And any result may require exponential time and space to calculate.

- -

This library, based on the paper linked at the top, solves all those problems and a few bits -more. As an example, the following grammar portion:

- -
-
-Expression ::= Expression - Term | Term
-Term ::= Term * Factor | Factor
-Factor ::= ( Expression ) | Integer
-
-
- -

Can be turned into the following code snippet:

- -
- -package Expr_Redir is new Redirect; -package Term_Redir is new Redirect; - -function Left_Parens is new Match ('('); -function Right_Parens is new Match (')'); -function Fac_Expr is new Between (Left_Parens, Expr_Redir.Call, Right_Parens); -function Fac_Choice is new Choice_2 (Fac_Expr, Integer_Num); -function Factor is new Stamp (Factor_Label, Fac_Choice); - -function Multiply is new Match ('*'); -function Term_Mult is new Sequence (Term_Redir.Call'Access, Multiply'Access, Factor'Access); -function Term_Choice is new Choice_2 (Term_Mult, Factor); -function Term is new Stamp (Term_Label, Term_Choice); - -function Minus is new Match ('-'); -function Expr_Minus is new Sequence (Expr_Redir.Call'Access, Minus'Access, Term'Access); -function Expr_Choice is new Choice_2 (Expr_Minus, Term); -function Expression is new Stamp (Expression_Label, Expr_Choice); - -
- -

Most of the verbosity is caused by the need to individually instantiate each combinator, as -generics are used to serve the same purpose as higher order functions. Some bits are also omitted, -such as the label enumeration and the actual setting of the redirectors. But the above should -provide a good general impression.

- - -
Features
- -

A list of features that this library provides includes:

- - -

More thorough documentation is provided in the /doc directory.

- -

The name of the library comes from packrat parsing which is a parsing algorithm that avoids exponential time -complexity by memoizing all intermediate results. As that is what this library does, both so as to -reduce the time complexity and to enable piecewise parsing, the name seemed appropriate.

- - -
Left Recursion
- -

Direct left recursion, meaning a grammar non-terminal that immediately recurses to itself on the -left as in the Expression or Term used above, is fairly easy to handle. A counter -is used to keep track of how many times a particular combinator has been applied to the input at a -particular position, and when that counter exceeds the number of unconsumed input tokens plus one -the result is curtailed. This is explained on pages 7 and 8 of the paper.

- -

The really thorny issue that caused the most problems with this library is indirect left -recursion. This is when a non-terminal recurses to itself on the left only after first evaluating to -one or more other non-terminals. Curtailment in these circumstances can easily cause those other -non-terminals to also be curtailed, and reusing the results for those other non-terminals may be -incorrect. This issue along with a proposed solution is explained on page 9 of the paper. However -that solution was not as clear as would be preferred. So some minor rephrasing and reworking was -needed.

- -

Bringing this problem back to the start: What are we really doing when we curtail a result due to -left recursion? It is not a matter of cutting off branches in a parse tree. We are identifying -conditions where the parse result of a particular non-terminal can be calculated without further -recursion. The word "curtailment" is somewhat misleading in this regard. Once this reframing is done -then a clearer view immediately follows.

- -

What is the condition? Exactly as described above for direct left recursion. Through comparing -recursion counts with the amount of unconsumed input we determine that a result of no successful -parse can be calculated, and that the result is valid for reuse for any deeper recursion of the same -combinator at that input position.

- -

From that can be derived:

- - -

So far the above list just covers what is in the paper. But there is a little more that can be -inferred:

- - -

These two details should constitute a minor efficiency improvement.

- - -
Further Work
- -

While the polynomial complexity of this library has been experimentally confirmed, no effort has -yet been made to prove that it is actually polynomial in the same way that the parser combinators in -the paper are. It is possible that due to the changes involved with using a non-functional language -and enabling piecewise parsing that some subtle complexity difference may have arisen.

- -

Likewise, the piecewise parsing has been unit tested to a degree but no formal proof that it is -correct has been done.

- -

Ideas like being able to modify and resume an erroneous parsing attempt would also be interesting -to explore.

- -

Finally, the plan is to actually use this library for something significant at some point in the -future.

-{% endblock -%} - diff --git a/project/templates/packrat.xhtml b/project/templates/packrat.xhtml new file mode 100644 index 0000000..ee33b41 --- /dev/null +++ b/project/templates/packrat.xhtml @@ -0,0 +1,167 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Packrat Parser Combinator Library{%- endblock -%} + + + +{%- block content %} +

Packrat Parser Combinator Library

+ +

Git repository: Link
+Paper this was based on: Link

+ +
2/2/2021
+ + +
Overview
+ +

Parser combinators are what you end up with when you start factoring out common pieces of +functionality from +recursive descent parsing. They are higher order functions that can be combined in modular ways +to create a desired parser.

+ +

However they also inherit the drawbacks of recursive descent parsing, and in particular recursive +descent parsing with backtracking. If the grammar that the parser is designed to accept contains +left recursion then the parser will loop infinitely. If the grammar is ambiguous then only one +result will be obtained. And any result may require exponential time and space to calculate.

+ +

This library, based on the paper linked at the top, solves all those problems and a few bits +more. As an example, the following grammar portion:

+ +
+
+Expression ::= Expression - Term | Term
+Term ::= Term * Factor | Factor
+Factor ::= ( Expression ) | Integer
+
+
+ +

Can be turned into the following code snippet:

+ +
+ +package Expr_Redir is new Redirect; +package Term_Redir is new Redirect; + +function Left_Parens is new Match ('('); +function Right_Parens is new Match (')'); +function Fac_Expr is new Between (Left_Parens, Expr_Redir.Call, Right_Parens); +function Fac_Choice is new Choice_2 (Fac_Expr, Integer_Num); +function Factor is new Stamp (Factor_Label, Fac_Choice); + +function Multiply is new Match ('*'); +function Term_Mult is new Sequence (Term_Redir.Call'Access, Multiply'Access, Factor'Access); +function Term_Choice is new Choice_2 (Term_Mult, Factor); +function Term is new Stamp (Term_Label, Term_Choice); + +function Minus is new Match ('-'); +function Expr_Minus is new Sequence (Expr_Redir.Call'Access, Minus'Access, Term'Access); +function Expr_Choice is new Choice_2 (Expr_Minus, Term); +function Expression is new Stamp (Expression_Label, Expr_Choice); + +
+ +

Most of the verbosity is caused by the need to individually instantiate each combinator, as +generics are used to serve the same purpose as higher order functions. Some bits are also omitted, +such as the label enumeration and the actual setting of the redirectors. But the above should +provide a good general impression.

+ + +
Features
+ +

A list of features that this library provides includes:

+ + +

More thorough documentation is provided in the /doc directory.

+ +

The name of the library comes from packrat parsing which is a parsing algorithm that avoids exponential time +complexity by memoizing all intermediate results. As that is what this library does, both so as to +reduce the time complexity and to enable piecewise parsing, the name seemed appropriate.

+ + +
Left Recursion
+ +

Direct left recursion, meaning a grammar non-terminal that immediately recurses to itself on the +left as in the Expression or Term used above, is fairly easy to handle. A counter +is used to keep track of how many times a particular combinator has been applied to the input at a +particular position, and when that counter exceeds the number of unconsumed input tokens plus one +the result is curtailed. This is explained on pages 7 and 8 of the paper.

+ +

The really thorny issue that caused the most problems with this library is indirect left +recursion. This is when a non-terminal recurses to itself on the left only after first evaluating to +one or more other non-terminals. Curtailment in these circumstances can easily cause those other +non-terminals to also be curtailed, and reusing the results for those other non-terminals may be +incorrect. This issue along with a proposed solution is explained on page 9 of the paper. However +that solution was not as clear as would be preferred. So some minor rephrasing and reworking was +needed.

+ +

Bringing this problem back to the start: What are we really doing when we curtail a result due to +left recursion? It is not a matter of cutting off branches in a parse tree. We are identifying +conditions where the parse result of a particular non-terminal can be calculated without further +recursion. The word "curtailment" is somewhat misleading in this regard. Once this reframing is done +then a clearer view immediately follows.

+ +

What is the condition? Exactly as described above for direct left recursion. Through comparing +recursion counts with the amount of unconsumed input we determine that a result of no successful +parse can be calculated, and that the result is valid for reuse for any deeper recursion of the same +combinator at that input position.

+ +

From that can be derived:

+ + +

So far the above list just covers what is in the paper. But there is a little more that can be +inferred:

+ + +

These two details should constitute a minor efficiency improvement.

+ + +
Further Work
+ +

While the polynomial complexity of this library has been experimentally confirmed, no effort has +yet been made to prove that it is actually polynomial in the same way that the parser combinators in +the paper are. It is possible that due to the changes involved with using a non-functional language +and enabling piecewise parsing that some subtle complexity difference may have arisen.

+ +

Likewise, the piecewise parsing has been unit tested to a degree but no formal proof that it is +correct has been done.

+ +

Ideas like being able to modify and resume an erroneous parsing attempt would also be interesting +to explore.

+ +

Finally, the plan is to actually use this library for something significant at some point in the +future.

+{% endblock -%} + diff --git a/project/templates/sokoban.html b/project/templates/sokoban.html deleted file mode 100644 index c3f9238..0000000 --- a/project/templates/sokoban.html +++ /dev/null @@ -1,38 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Sokoban Clone{%- endblock -%} - - - -{%- block content %} -

Sokoban Clone

- -

Git repository: Link

- -
8/8/2017
- -

Back when I was studying computer science at university, there was an assignment involving -Sokoban. We were tasked with -completing a half written implementation in Java and Swing. This is not that implementation. It is, -however, based on it. Recently while going over old notes I found the assignment. The submission I -had originally made is lost to time, but it seemed like a nice quick diversion to get some more use -out of the FLTK Ada binding.

- -
- The first level -
The first level
-
- -

This is a vanilla version, so the only mechanic is pushing blocks to specific goal tiles. -Controls are simple enough that instructions can be left permanently written at the bottom of the -window. An A* Search -algorithm is used for the mouse control.

-{% endblock -%} - - diff --git a/project/templates/sokoban.xhtml b/project/templates/sokoban.xhtml new file mode 100644 index 0000000..0ce990a --- /dev/null +++ b/project/templates/sokoban.xhtml @@ -0,0 +1,38 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Sokoban Clone{%- endblock -%} + + + +{%- block content %} +

Sokoban Clone

+ +

Git repository: Link

+ +
8/8/2017
+ +

Back when I was studying computer science at university, there was an assignment involving +Sokoban. We were tasked with +completing a half written implementation in Java and Swing. This is not that implementation. It is, +however, based on it. Recently while going over old notes I found the assignment. The submission I +had originally made is lost to time, but it seemed like a nice quick diversion to get some more use +out of the FLTK Ada binding.

+ +
+ The first level +
The first level
+
+ +

This is a vanilla version, so the only mechanic is pushing blocks to specific goal tiles. +Controls are simple enough that instructions can be left permanently written at the bottom of the +window. An A* Search +algorithm is used for the mouse control.

+{% endblock -%} + + diff --git a/project/templates/steelman.html b/project/templates/steelman.html deleted file mode 100644 index 3ae2d95..0000000 --- a/project/templates/steelman.html +++ /dev/null @@ -1,2437 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}D, Parasail, Pascal and Rust vs The Steelman{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

D, Parasail, Pascal, and Rust vs The Steelman

- -
29/10/2017
- - -
Overview
- -

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. -

- -

In 1996 David A. Wheeler wrote a paper 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.

- - -
The Languages
- -

D 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.

- -

Parasail 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, simplifying and adding static checking to eliminate as many sources of errors -as possible. It represents a possible future direction for Ada derived languages.

- -

Pascal -, 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 -teaching -algorithms. 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.

- -

Rust 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 affine typing.

- - - - - - - - - - -
-
- Logo for the D programming language -
D
-
- 		-
- Logo for the Parasail programming language -
Parasail
-
-
-
- A picture of Blaise Pascal to stand in as a logo for the Pascal programming language -
Pascal*
-
- 		-
- Logo for the Rust programming language -
Rust
-
-
- -

* Pascal does not have an official logo, so a picture of -Blaise Pascal, in whose -honour the language is named, will have to do.

- - -
Rules for Comparison
- -

The rule used for this article is that a language provides a feature if:

-
    -
  1. that feature is defined in the documents widely regarded as the language's defining - document(s), or
    2. -
  2. that feature is widely implemented by compilers typically used for that language with - essentially the same semantics.
    3. -
- -

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.

- -

The defining documents used for each of these languages are as follows:

- - - -
Results and Conclusions
- -

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Language"No""Partial""Mostly""Yes"Percentage with "Mostly" or "Yes"
D715256681%
Parasail116118585%
Pascal1916116769%
Rust1219235973%
- -

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.

- -

The following are high level comments on these programming languages and how they relate:

- - - -
Appendix: Table Comparing the Languages to Steelman
- -

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.

- -

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.

- - -
- - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
RequirementDParasailPascalRust
- 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. - yesno?yes?yes?
- Parasail does not specify ways to directly control hardware, nor any interfaces to other - languages. -
- 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. - yes?yespartial?mostly?
-
- 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. - partial?yes?mostly?partial?
- 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. -
- 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. - partial?yes?yesyes?
- D incorporates garbage collection to some extent. Parasail is designed to allow as much - implicit parallelism as possible. -
- 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. - yes?mostlyyesyes
- Parasail allows several syntactical forms that are identical in meaning. -
- 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. - yesyesyesyes
- All of these languages have been reasonably implemented. -
- 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. - yesyesyesyes
-
- 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. - yesyesmostly?mostly?
- 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. -
- 2A. Character Set. The full set of character graphics that may be used in source - programs shall be given in the language definition. Every source program shall also have - a representation that uses only the following 55 character subset of the ASCII graphics: - %&'()*+,-./:;<=>? 0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ_ Each additional - graphic (i.e., one in the full set but not in the 55 character set) may be replaced by a - sequence of (one or more) characters from the 55 character set without altering the - semantics of the program. The replacement sequence shall be specified in the language - definition. - mostlymostlymostlymostly
-
- 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. - partial?yesyespartial?
- 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. -
- 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. - yesyesyesno
- Rust has macros, which can be used to add new syntax to the language. -
- 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. - mostlyyesmostlymostly
- D, Pascal, and Rust permit multi line comments. D and Rust use opening and closing - braces rather than key words. -
- 2E. Mnemonic Identifiers. Mnemonically significant identifiers shall be allowed. There - shall be a break character for use within identifiers. The language and its translators - shall not permit identifiers or reserved words to be abbreviated. (Note that this does - not preclude reserved words that are abbreviations of natural language words.) - yesyesyesyes
-
- 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. - yesyesyesyes
-
- 2G. Numeric Literals. There shall be built-in decimal literals. There shall be no - implicit truncation or rounding of integer and fixed point literals. - mostlyyesmostly?mostly
- 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. -
- 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. - yesyesyesyes
- Univ_Strings in Parasail are vectors of Univ_Character, not arrays. -
- 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. - yesyespartialyes
- Line comments were introduced in Turbo Pascal, but are not part of the ISO standard. -
- 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. - mostlyyesyesyes
- 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. -
- 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. - partial?yesyes?partial?
- 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. -
- 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. - mostlyyesyes?mostly
- D, Rust do not have subtypes. D however can emulate similar functionality with type - invariant contracts for user defined classes. -
- 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.] - partialyes?mostly?no
- D does not have subtypes but has similar functionality with class type invariants. Rust - doesn't have subtypes at all. -
- 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. - partial?yespartial?mostly?
- 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. -
- 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. - mostlyyesmostlymostly
- 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. -
- 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. - yesyesyesyes
- 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. -
- 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. - mostlyyesnomostly
- 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. -
- 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. - yesyes?partialyes?
- 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. -
- 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. - mostlyyespartialmostly
- 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. -
- 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. - noyesnono
- Of these four languages, only Parasail supports fixed point types. -
- 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. - noyesnono
- All support "modulo" operators; D, Pascal, Rust don't support fixed point numbers. -
- 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. - mostlyyesyesmostly
- 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. -
- 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. - yesyes?yes?mostly?
-
- 3-2C. Boolean Type. There shall be a predefined type for Boolean values. - yesyesyesyes
- D's boolean type is weakly typed. -
- 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. - yesyesyesyes
-
- 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). - yesyesyesyes
- All have arrays and records. -
- 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. - yesyesyesyes
- Range, precision, and scale specifications are included in numeric type definitions - (with support varying, see 3-1). -
- 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. - yesyesyesyes
-
- 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. - mostlyyesyesmostly
- D and Rust array indexes can only start at zero and cannot use enumerations. -
- 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. - yesyes?nopartial
- 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. -
- 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. - yesyesno?no?
- D classes can include constants and functions. Parasail type inferfaces can include - constants and functions. -
- 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. - yesyes?yesyes
- 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". -
- 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. - yesyes?yes?yes
-
- 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.] - yesyesyesyes
-
- 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. - yesyesyesyes
-
- 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). - yesyesyespartial
- 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. -
- 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. - yesyes?yespartial
-
- 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. - yesyesyesyes
- All of these languages have modules as their unit of encapsulation. -
- 3-5B. Effect of Encapsulation. An encapsulation may be used to inhibit external access - to implementation properties of the definition. In particular, it shall be possible to - prevent external reference to any declaration within the encapsulation including - automatically defined operations such as type conversions and equality. Definitions that - are made within an encapsulation and are externally accessible may be renamed before use - outside the encapsulation. - yesyesyesyes
-
- 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. - yesyesyesyes
-
- 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. - yesyesyesyes
-
- 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). - yesyesyesyes
-
- 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.] - mostly?yes?mostly?mostly?
- Parasail does not permit global variables. -
- 4D. Allowed Usage. Expressions of a given type shall be allowed wherever both constants - and variables of the type are allowed. - yesyesyesyes
-
- 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. - yesyesyesyes
-
- 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. - mostlyyesyesmostly
- 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. -
- 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.] - yesyesyesyes
-
- 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. - yesyesyesyes
-
- 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.] - mostlyyesyespartial
- 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. -
- 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. - yes?yesyesyes?
-
- 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. - nonono?no
- D and Pascal allow pointers to functions. Parasail allows lambda expressions. Rust has - first class functions. -
- 5E. Initial Values. There shall be no default initial-values for variables. - partialpartialpartial?mostly
- 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. -
- 5F. Operations on Variables. Assignment and an implicit value access operation shall be - automatically defined for each variable. - yesyesyesyes
-
- 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. - yesyesyesyes
-
- 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). - yesyesyesyes
-
- 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. - yesyesyesyes
- D and Rust use statement terminators. Pascal and Parasail use statement separators. -
- 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. - yesyesyesyes
-
- 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. - yesyespartialyes
- Standard Pascal does not provide infix control operations, but both Extended Pascal and - Turbo Pascal do. -
- 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. - mostlyyesyesyes
- In D, the loop control variable is not considered a constant. -
- 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. - yes?partialyespartial?
- Neither Parasail nor Rust support goto. However both support break/continue statements - that serve the same purpose in many cases. -
- 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.] - yesyesyesno
- Rust does not support ad-hoc polymorphism. It must be emulated using the trait system. -
- 7B. Recursion. It shall be possible to call functions and procedures recursively. - yesyesyesyes
-   -
- 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. - yesyesyesyes
-
- 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. - mostlymostlymostly?mostly
-
- 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. - partialyespartial?partial?
- D, Pascal and Rust do not identify in, in-out and out parameters. D, Pascal and Rust can - support in-only parameters. -
- 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. - yes?yesyesyes?
-
- 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. - noyesyesno
- Subscript ranges are not accessible in D or Rust. -
- 7I. Restrictions to Prevent Aliasing. The language shall attempt to prevent aliasing - (i.e., multiple access paths to the same variable or record component) that is not - intended, but shall not prohibit all aliasing. Aliasing shall not be permitted between - output parameters nor between an input-output parameter and a nonlocal variable. - Unintended aliasing shall not be permitted between input-output parameters. A - restriction limiting actual input-output parameters to variables that are nowhere - referenced as nonlocals within a function or routine, is not prohibited. All aliasing of - components of elements of an indirect type shall be considered intentional. - noyesyes?yes
-
- 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. - partial?no?partial?no?
- D and some Pascal dialects permit access to memory mapped locations. -
- 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. - yesyesyesyes
-
- 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). - yesyesyesyes
-
- 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.] - yesyesyesyes
-
- 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. - mostlymostlypartialno
- 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. -
- 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. - yesyesyespartial
- In Rust, operations to convert between enumerations and strings are not predefined. -
- 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). - yesmostlynoyes
- 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. -
- 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. - yesyesnoyes
-
- 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. - partial?yesnoyes
- D supports shared variables and atomic operations, however the idiomatic way of - threading is to rely on immutable data and message passing. -
- 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.] - yes?yes?nopartial?
-
- 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. - yesyesyes?yes?
- D provides this in core.time. Parasail provides this in its standard library. -
- 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. - yesno?noyes
- 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. -
- 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. - yesyesnoyes
- D synchronized calls allow this. Rust achieves this with std::sync::mpsc. -
- 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. - mostly?mostly?nomostly?
-
- 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). - mostly?mostly?nomostly?
-
- 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. - yespartial?partial?partial
- 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. -
- 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).] - partial?mostlypartialpartial?
- Parasail is constructed to detect all of these mentioned errors, except the out of - memory error, at compile time. -
- 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. - yespartialpartialpartial
- 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. -
- 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. - yesno?partialno
- Standard Pascal does not specify how to handle errors, whether exceptions or otherwise, - see 10A. -
- 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. - yes?yesyesyes
-
- 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.] - mostlymostlynomostly
- None? of these languages permit assertions of frequency. -
- 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.] - partialnonono
- It is possible to statically disallow code from throwing exceptions in D, but that - doesn't fulfil the same function as this requirement. -
- 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). - partial?no?nopartial
-
- 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. - partialpartial?nopartial
-
- 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.] - no?no?nono?
-
- 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. - yesnomostlyyes
- 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. -
- 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). - partial?no?partial?partial?
-
- 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. - yesyesyesyes
-
- 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. - mostly?yes?yes?yes?
-
- 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. - yesyespartialmostly
- 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. -
- 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. - mostly?mostly?yespartial
-
- 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. - nonoyesno
-
- 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. - mostly?yesyesmostly
-
- 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. - mostly?yesyes?yes?
-
- 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. - mostlymostlymostlymostly
- 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. -
- 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. - yesyesyes?yes
-
- 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. - mostlypartialyespartial
-
- -
-
-{% endblock -%} - - diff --git a/project/templates/steelman.xhtml b/project/templates/steelman.xhtml new file mode 100644 index 0000000..11136cf --- /dev/null +++ b/project/templates/steelman.xhtml @@ -0,0 +1,2437 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}D, Parasail, Pascal and Rust vs The Steelman{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

D, Parasail, Pascal, and Rust vs The Steelman

+ +
29/10/2017
+ + +
Overview
+ +

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. +

+ +

In 1996 David A. Wheeler wrote a paper 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.

+ + +
The Languages
+ +

D 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.

+ +

Parasail 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, simplifying and adding static checking to eliminate as many sources of errors +as possible. It represents a possible future direction for Ada derived languages.

+ +

Pascal +, 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 +teaching +algorithms. 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.

+ +

Rust 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 affine typing.

+ + + + + + + + + + +
+
+ Logo for the D programming language +
D
+
+ 		+
+ Logo for the Parasail programming language +
Parasail
+
+
+
+ A picture of Blaise Pascal to stand in as a logo for the Pascal programming language +
Pascal*
+
+ 		+
+ Logo for the Rust programming language +
Rust
+
+
+ +

* Pascal does not have an official logo, so a picture of +Blaise Pascal, in whose +honour the language is named, will have to do.

+ + +
Rules for Comparison
+ +

The rule used for this article is that a language provides a feature if:

+
    +
  1. that feature is defined in the documents widely regarded as the language's defining + document(s), or
    2. +
  2. that feature is widely implemented by compilers typically used for that language with + essentially the same semantics.
    3. +
+ +

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.

+ +

The defining documents used for each of these languages are as follows:

+ + + +
Results and Conclusions
+ +

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Language"No""Partial""Mostly""Yes"Percentage with "Mostly" or "Yes"
D715256681%
Parasail116118585%
Pascal1916116769%
Rust1219235973%
+ +

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.

+ +

The following are high level comments on these programming languages and how they relate:

+ + + +
Appendix: Table Comparing the Languages to Steelman
+ +

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.

+ +

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.

+ + +
+ + +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
RequirementDParasailPascalRust
+ 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. + yesno?yes?yes?
+ Parasail does not specify ways to directly control hardware, nor any interfaces to other + languages. +
+ 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. + yes?yespartial?mostly?
+
+ 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. + partial?yes?mostly?partial?
+ 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. +
+ 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. + partial?yes?yesyes?
+ D incorporates garbage collection to some extent. Parasail is designed to allow as much + implicit parallelism as possible. +
+ 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. + yes?mostlyyesyes
+ Parasail allows several syntactical forms that are identical in meaning. +
+ 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. + yesyesyesyes
+ All of these languages have been reasonably implemented. +
+ 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. + yesyesyesyes
+
+ 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. + yesyesmostly?mostly?
+ 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. +
+ 2A. Character Set. The full set of character graphics that may be used in source + programs shall be given in the language definition. Every source program shall also have + a representation that uses only the following 55 character subset of the ASCII graphics: + %&'()*+,-./:;<=>? 0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ_ Each additional + graphic (i.e., one in the full set but not in the 55 character set) may be replaced by a + sequence of (one or more) characters from the 55 character set without altering the + semantics of the program. The replacement sequence shall be specified in the language + definition. + mostlymostlymostlymostly
+
+ 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. + partial?yesyespartial?
+ 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. +
+ 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. + yesyesyesno
+ Rust has macros, which can be used to add new syntax to the language. +
+ 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. + mostlyyesmostlymostly
+ D, Pascal, and Rust permit multi line comments. D and Rust use opening and closing + braces rather than key words. +
+ 2E. Mnemonic Identifiers. Mnemonically significant identifiers shall be allowed. There + shall be a break character for use within identifiers. The language and its translators + shall not permit identifiers or reserved words to be abbreviated. (Note that this does + not preclude reserved words that are abbreviations of natural language words.) + yesyesyesyes
+
+ 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. + yesyesyesyes
+
+ 2G. Numeric Literals. There shall be built-in decimal literals. There shall be no + implicit truncation or rounding of integer and fixed point literals. + mostlyyesmostly?mostly
+ 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. +
+ 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. + yesyesyesyes
+ Univ_Strings in Parasail are vectors of Univ_Character, not arrays. +
+ 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. + yesyespartialyes
+ Line comments were introduced in Turbo Pascal, but are not part of the ISO standard. +
+ 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. + mostlyyesyesyes
+ 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. +
+ 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. + partial?yesyes?partial?
+ 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. +
+ 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. + mostlyyesyes?mostly
+ D, Rust do not have subtypes. D however can emulate similar functionality with type + invariant contracts for user defined classes. +
+ 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.] + partialyes?mostly?no
+ D does not have subtypes but has similar functionality with class type invariants. Rust + doesn't have subtypes at all. +
+ 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. + partial?yespartial?mostly?
+ 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. +
+ 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. + mostlyyesmostlymostly
+ 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. +
+ 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. + yesyesyesyes
+ 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. +
+ 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. + mostlyyesnomostly
+ 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. +
+ 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. + yesyes?partialyes?
+ 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. +
+ 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. + mostlyyespartialmostly
+ 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. +
+ 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. + noyesnono
+ Of these four languages, only Parasail supports fixed point types. +
+ 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. + noyesnono
+ All support "modulo" operators; D, Pascal, Rust don't support fixed point numbers. +
+ 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. + mostlyyesyesmostly
+ 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. +
+ 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. + yesyes?yes?mostly?
+
+ 3-2C. Boolean Type. There shall be a predefined type for Boolean values. + yesyesyesyes
+ D's boolean type is weakly typed. +
+ 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. + yesyesyesyes
+
+ 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). + yesyesyesyes
+ All have arrays and records. +
+ 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. + yesyesyesyes
+ Range, precision, and scale specifications are included in numeric type definitions + (with support varying, see 3-1). +
+ 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. + yesyesyesyes
+
+ 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. + mostlyyesyesmostly
+ D and Rust array indexes can only start at zero and cannot use enumerations. +
+ 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. + yesyes?nopartial
+ 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. +
+ 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. + yesyesno?no?
+ D classes can include constants and functions. Parasail type inferfaces can include + constants and functions. +
+ 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. + yesyes?yesyes
+ 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". +
+ 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. + yesyes?yes?yes
+
+ 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.] + yesyesyesyes
+
+ 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. + yesyesyesyes
+
+ 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). + yesyesyespartial
+ 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. +
+ 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. + yesyes?yespartial
+
+ 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. + yesyesyesyes
+ All of these languages have modules as their unit of encapsulation. +
+ 3-5B. Effect of Encapsulation. An encapsulation may be used to inhibit external access + to implementation properties of the definition. In particular, it shall be possible to + prevent external reference to any declaration within the encapsulation including + automatically defined operations such as type conversions and equality. Definitions that + are made within an encapsulation and are externally accessible may be renamed before use + outside the encapsulation. + yesyesyesyes
+
+ 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. + yesyesyesyes
+
+ 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. + yesyesyesyes
+
+ 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). + yesyesyesyes
+
+ 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.] + mostly?yes?mostly?mostly?
+ Parasail does not permit global variables. +
+ 4D. Allowed Usage. Expressions of a given type shall be allowed wherever both constants + and variables of the type are allowed. + yesyesyesyes
+
+ 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. + yesyesyesyes
+
+ 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. + mostlyyesyesmostly
+ 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. +
+ 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.] + yesyesyesyes
+
+ 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. + yesyesyesyes
+
+ 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.] + mostlyyesyespartial
+ 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. +
+ 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. + yes?yesyesyes?
+
+ 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. + nonono?no
+ D and Pascal allow pointers to functions. Parasail allows lambda expressions. Rust has + first class functions. +
+ 5E. Initial Values. There shall be no default initial-values for variables. + partialpartialpartial?mostly
+ 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. +
+ 5F. Operations on Variables. Assignment and an implicit value access operation shall be + automatically defined for each variable. + yesyesyesyes
+
+ 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. + yesyesyesyes
+
+ 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). + yesyesyesyes
+
+ 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. + yesyesyesyes
+ D and Rust use statement terminators. Pascal and Parasail use statement separators. +
+ 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. + yesyesyesyes
+
+ 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. + yesyespartialyes
+ Standard Pascal does not provide infix control operations, but both Extended Pascal and + Turbo Pascal do. +
+ 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. + mostlyyesyesyes
+ In D, the loop control variable is not considered a constant. +
+ 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. + yes?partialyespartial?
+ Neither Parasail nor Rust support goto. However both support break/continue statements + that serve the same purpose in many cases. +
+ 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.] + yesyesyesno
+ Rust does not support ad-hoc polymorphism. It must be emulated using the trait system. +
+ 7B. Recursion. It shall be possible to call functions and procedures recursively. + yesyesyesyes
+   +
+ 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. + yesyesyesyes
+
+ 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. + mostlymostlymostly?mostly
+
+ 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. + partialyespartial?partial?
+ D, Pascal and Rust do not identify in, in-out and out parameters. D, Pascal and Rust can + support in-only parameters. +
+ 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. + yes?yesyesyes?
+
+ 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. + noyesyesno
+ Subscript ranges are not accessible in D or Rust. +
+ 7I. Restrictions to Prevent Aliasing. The language shall attempt to prevent aliasing + (i.e., multiple access paths to the same variable or record component) that is not + intended, but shall not prohibit all aliasing. Aliasing shall not be permitted between + output parameters nor between an input-output parameter and a nonlocal variable. + Unintended aliasing shall not be permitted between input-output parameters. A + restriction limiting actual input-output parameters to variables that are nowhere + referenced as nonlocals within a function or routine, is not prohibited. All aliasing of + components of elements of an indirect type shall be considered intentional. + noyesyes?yes
+
+ 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. + partial?no?partial?no?
+ D and some Pascal dialects permit access to memory mapped locations. +
+ 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. + yesyesyesyes
+
+ 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). + yesyesyesyes
+
+ 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.] + yesyesyesyes
+
+ 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. + mostlymostlypartialno
+ 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. +
+ 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. + yesyesyespartial
+ In Rust, operations to convert between enumerations and strings are not predefined. +
+ 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). + yesmostlynoyes
+ 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. +
+ 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. + yesyesnoyes
+
+ 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. + partial?yesnoyes
+ D supports shared variables and atomic operations, however the idiomatic way of + threading is to rely on immutable data and message passing. +
+ 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.] + yes?yes?nopartial?
+
+ 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. + yesyesyes?yes?
+ D provides this in core.time. Parasail provides this in its standard library. +
+ 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. + yesno?noyes
+ 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. +
+ 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. + yesyesnoyes
+ D synchronized calls allow this. Rust achieves this with std::sync::mpsc. +
+ 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. + mostly?mostly?nomostly?
+
+ 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). + mostly?mostly?nomostly?
+
+ 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. + yespartial?partial?partial
+ 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. +
+ 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).] + partial?mostlypartialpartial?
+ Parasail is constructed to detect all of these mentioned errors, except the out of + memory error, at compile time. +
+ 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. + yespartialpartialpartial
+ 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. +
+ 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. + yesno?partialno
+ Standard Pascal does not specify how to handle errors, whether exceptions or otherwise, + see 10A. +
+ 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. + yes?yesyesyes
+
+ 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.] + mostlymostlynomostly
+ None? of these languages permit assertions of frequency. +
+ 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.] + partialnonono
+ It is possible to statically disallow code from throwing exceptions in D, but that + doesn't fulfil the same function as this requirement. +
+ 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). + partial?no?nopartial
+
+ 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. + partialpartial?nopartial
+
+ 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.] + no?no?nono?
+
+ 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. + yesnomostlyyes
+ 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. +
+ 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). + partial?no?partial?partial?
+
+ 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. + yesyesyesyes
+
+ 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. + mostly?yes?yes?yes?
+
+ 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. + yesyespartialmostly
+ 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. +
+ 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. + mostly?mostly?yespartial
+
+ 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. + nonoyesno
+
+ 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. + mostly?yesyesmostly
+
+ 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. + mostly?yesyes?yes?
+
+ 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. + mostlymostlymostlymostly
+ 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. +
+ 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. + yesyesyes?yes
+
+ 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. + mostlypartialyespartial
+
+ +
+
+{% endblock -%} + + diff --git a/project/templates/stvcount.html b/project/templates/stvcount.html deleted file mode 100644 index 8d4c3ae..0000000 --- a/project/templates/stvcount.html +++ /dev/null @@ -1,304 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Single Transferable Vote Counter{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

Single Transferable Vote Counter

- -

Git repository: Link

- -
19/2/2017
- -

To give an incredibly brief summary of Australia's political system, both the Federal Parliament and most of the State -Parliaments are bicameral. The lower houses are generally elected by Instant Runoff, while the upper -houses generally have half elections using Single Transferable Vote. There are exceptions and a -whole lot of differing details, but that's the overall pattern.

- -

In 2016, however, the Federal Parliament underwent a Double Dissolution, causing the entirety of -both houses to go to an election. This had the outcome of 20 out of 76 seats going to third parties -in the upper house, a record number. Even more than the 18 there were prior. As the entire purpose -of a Double Dissolution is to break deadlocks in parliament, to have the outcome go in the -complete opposite direction probably caused some dismay from Malcolm Turnbull -and his Liberal/National government.

- -

This raises the question: Would they have been better off had a normal election happened instead? -

- -

To calculate the likely outcome, the ballot preference data is needed. That's the easy part, as -the Australian Electoral Commission makes that available - -here in the 'Formal preferences' section. Then, a program is needed to execute the STV -algorithm, which is as follows:

- -
    -
  1. Set the quota of votes required for a candidate to win.
    2. -
  2. Allocate the ballot papers according to first preference to each of the candidates for - initial vote totals.
    3. -
  3. Mark any candidate who has reached or exceeded the quota as elected.
    4. -
  4. If any elected candidate has more votes than the quota, transfer the excess to the other - candidates according to the next applicable preference.
    5. -
  5. If no further candidates meet the quota, the candidate with the fewest votes is eliminated - and their votes are transferred to the others according to next applicable preference.
    6. -
  6. Repeat steps 3-5 until all seats are filled.
    7. -
- -

Seems simple enough, right? Except not really. There is a surprising amount of complexity in -there, and most of it is to do with how to transfer votes around. So, in addition, there are the -specifics for the version used for the Australian Senate:

- - - -

My implementation also includes bulk exclusions using applied breakpoints in order to increase speed slightly -and minimise superfluous logging.

- -

At this point I'm fairly sure my program provides an accurate count. However, my numbers still -differ slightly from the ones provided by the AEC's official distribution of preferences. -Investigations into the exact cause are ongoing.

- -

Results

- -

Calculations were done for each state using the formal preference data with vacancies set to 6 -instead of 12, and the results were added to the Senators elected in 2013 to find the probable -outcome. The results for ACT and NT were taken as-is, because the few Senators elected from the -territories are not part of the half election cadence anyway.

- -

Computational resources required varied from approximately 50 seconds using 46MB of memory for -Tasmania, to nearly 30 minutes using 1452MB memory for NSW. The vast majority of that time was spent -parsing preference data, and the program is single threaded, so there is still room for improvement. -All counts were run on a Core 2 Quad Q9500.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Probable non-DD results by state
NSWVICQLDSAWATAS
 Liberal Liberal Liberal National Liberal Liberal Liberal
 Labor Labor Labor Labor Labor Labor
 Liberal National Liberal National Xenophon Liberal Liberal
 Labor Labor Labor Liberal Labor Labor
 National Green One Nation Labor Green Jacqui Lambie
 Green Derryn Hinch Liberal National Xenophon Liberal Green
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Probable non-DD Senate composition
PartySeats WonContinuing SenatorsTotal SeatsDifference From Actual
 Liberal/National Coalition171532+2
 Australian Labor Party141024-2
 Australian Greens448-1
 Xenophon Group213Nil
 Jacqui Lambie Network*112+1
 Liberal Democratic Party011Nil
 Family First Party011Nil
 Palmer United Party*011+1
 Glenn Lazarus Team*011+1
 Australian Motoring Enthusiast Party011+1
 One Nation101-3
 Derryn Hinch's Justice Party101Nil
- -

* These three parties were all part of the Palmer United Party at the 2013/2014 election, but -split up mid term.

- -

Surprisingly, these projected results still have 20 out of 76 seats held by third party -candidates, despite the half election putting them at a disadvantage. The number of third party -groups the Liberal/Nationals have to negotiate with to pass legislation (assuming Labor and Greens -attempt to block) equally remains unchanged.

- -

The Greens manage to do slightly worse, even though their usual position of winning the 5th or -6th seat in most states often allows them to obtain more representation than their primary vote -would otherwise support. This can't even be attributed to a bad 2013 result, as their primary vote -both then and in 2016 was nearly identical.

- -

One Nation's much reduced number of seats can be attributed to the inherent geographic bias that -any system involving electing candidates across many independent divisions has. If like-minded -voters are all in one place, they receive representation, but when the same number of voters are -spread out, they get nothing. When this effect is intentionally exploited it's called -gerrymandering, but here it's merely an artifact of electing Senators from each state separately. -One Nation's support is strongest in Queensland but is relatively diffuse. Any claims of Pauline -Hanson being one of the most powerful politicians in Australia are thus -overblown.

- -

The Xenophon Group, by contrast, has the vast majority of their support concentrated in South -Australia. So the result for them remains unchanged.

- -

The most noteworthy outcomes for the question though, are that the Liberal/Nationals would have -obtained more seats, and Labor would have been in a more difficult position to block the passage of -legislation. Meaning that yes, the Liberal/National government would definitely have been better off -with a normal election.

- -

Nice job screwing over your own party, Malcolm.

-{% endblock -%} - - diff --git a/project/templates/stvcount.xhtml b/project/templates/stvcount.xhtml new file mode 100644 index 0000000..2cb3dda --- /dev/null +++ b/project/templates/stvcount.xhtml @@ -0,0 +1,304 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Single Transferable Vote Counter{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

Single Transferable Vote Counter

+ +

Git repository: Link

+ +
19/2/2017
+ +

To give an incredibly brief summary of Australia's political system, both the Federal Parliament and most of the State +Parliaments are bicameral. The lower houses are generally elected by Instant Runoff, while the upper +houses generally have half elections using Single Transferable Vote. There are exceptions and a +whole lot of differing details, but that's the overall pattern.

+ +

In 2016, however, the Federal Parliament underwent a Double Dissolution, causing the entirety of +both houses to go to an election. This had the outcome of 20 out of 76 seats going to third parties +in the upper house, a record number. Even more than the 18 there were prior. As the entire purpose +of a Double Dissolution is to break deadlocks in parliament, to have the outcome go in the +complete opposite direction probably caused some dismay from Malcolm Turnbull +and his Liberal/National government.

+ +

This raises the question: Would they have been better off had a normal election happened instead? +

+ +

To calculate the likely outcome, the ballot preference data is needed. That's the easy part, as +the Australian Electoral Commission makes that available + +here in the 'Formal preferences' section. Then, a program is needed to execute the STV +algorithm, which is as follows:

+ +
    +
  1. Set the quota of votes required for a candidate to win.
    2. +
  2. Allocate the ballot papers according to first preference to each of the candidates for + initial vote totals.
    3. +
  3. Mark any candidate who has reached or exceeded the quota as elected.
    4. +
  4. If any elected candidate has more votes than the quota, transfer the excess to the other + candidates according to the next applicable preference.
    5. +
  5. If no further candidates meet the quota, the candidate with the fewest votes is eliminated + and their votes are transferred to the others according to next applicable preference.
    6. +
  6. Repeat steps 3-5 until all seats are filled.
    7. +
+ +

Seems simple enough, right? Except not really. There is a surprising amount of complexity in +there, and most of it is to do with how to transfer votes around. So, in addition, there are the +specifics for the version used for the Australian Senate:

+ + + +

My implementation also includes bulk exclusions using applied breakpoints in order to increase speed slightly +and minimise superfluous logging.

+ +

At this point I'm fairly sure my program provides an accurate count. However, my numbers still +differ slightly from the ones provided by the AEC's official distribution of preferences. +Investigations into the exact cause are ongoing.

+ +

Results

+ +

Calculations were done for each state using the formal preference data with vacancies set to 6 +instead of 12, and the results were added to the Senators elected in 2013 to find the probable +outcome. The results for ACT and NT were taken as-is, because the few Senators elected from the +territories are not part of the half election cadence anyway.

+ +

Computational resources required varied from approximately 50 seconds using 46MB of memory for +Tasmania, to nearly 30 minutes using 1452MB memory for NSW. The vast majority of that time was spent +parsing preference data, and the program is single threaded, so there is still room for improvement. +All counts were run on a Core 2 Quad Q9500.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Probable non-DD results by state
NSWVICQLDSAWATAS
 Liberal Liberal Liberal National Liberal Liberal Liberal
 Labor Labor Labor Labor Labor Labor
 Liberal National Liberal National Xenophon Liberal Liberal
 Labor Labor Labor Liberal Labor Labor
 National Green One Nation Labor Green Jacqui Lambie
 Green Derryn Hinch Liberal National Xenophon Liberal Green
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Probable non-DD Senate composition
PartySeats WonContinuing SenatorsTotal SeatsDifference From Actual
 Liberal/National Coalition171532+2
 Australian Labor Party141024-2
 Australian Greens448-1
 Xenophon Group213Nil
 Jacqui Lambie Network*112+1
 Liberal Democratic Party011Nil
 Family First Party011Nil
 Palmer United Party*011+1
 Glenn Lazarus Team*011+1
 Australian Motoring Enthusiast Party011+1
 One Nation101-3
 Derryn Hinch's Justice Party101Nil
+ +

* These three parties were all part of the Palmer United Party at the 2013/2014 election, but +split up mid term.

+ +

Surprisingly, these projected results still have 20 out of 76 seats held by third party +candidates, despite the half election putting them at a disadvantage. The number of third party +groups the Liberal/Nationals have to negotiate with to pass legislation (assuming Labor and Greens +attempt to block) equally remains unchanged.

+ +

The Greens manage to do slightly worse, even though their usual position of winning the 5th or +6th seat in most states often allows them to obtain more representation than their primary vote +would otherwise support. This can't even be attributed to a bad 2013 result, as their primary vote +both then and in 2016 was nearly identical.

+ +

One Nation's much reduced number of seats can be attributed to the inherent geographic bias that +any system involving electing candidates across many independent divisions has. If like-minded +voters are all in one place, they receive representation, but when the same number of voters are +spread out, they get nothing. When this effect is intentionally exploited it's called +gerrymandering, but here it's merely an artifact of electing Senators from each state separately. +One Nation's support is strongest in Queensland but is relatively diffuse. Any claims of Pauline +Hanson being one of the most powerful politicians in Australia are thus +overblown.

+ +

The Xenophon Group, by contrast, has the vast majority of their support concentrated in South +Australia. So the result for them remains unchanged.

+ +

The most noteworthy outcomes for the question though, are that the Liberal/Nationals would have +obtained more seats, and Labor would have been in a more difficult position to block the passage of +legislation. Meaning that yes, the Liberal/National government would definitely have been better off +with a normal election.

+ +

Nice job screwing over your own party, Malcolm.

+{% endblock -%} + + diff --git a/project/templates/sunset.html b/project/templates/sunset.html deleted file mode 100644 index bfad239..0000000 --- a/project/templates/sunset.html +++ /dev/null @@ -1,63 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Sunset License{%- endblock -%} - - - -{%- block content %} -

Sunset License

- -

Git repository: Link

- -
29/6/2017
- -

Software licenses bother me. As a general rule I prefer to make my projects open source, -and for that purpose something like the Unlicense - is often sufficient. But if I don't want to put my work in the public domain immediately, then -I have to make use of a copyleft license. -And all of the ones currently available are both incredibly, unnecessarily verbose, and fail to -address the primary failing of modern copyright law, which is the unreasonably long term lengths. -

- -

So after a considerable amount of thought, I've written my own. (I can hear those with legal -knowledge wailing and gnashing their teeth already.) Care has been taken to mimic the phrasing used -in popular existing licenses where possible. I've also kept it as simple and as straightforward as I -can make it. So hopefully there are no loopholes and it's exactly as it appears: a simple weak -copyleft license which places older parts of a work under a public domain disclaimer in a reasonable -timeframe.

- -

The full text is as follows:

-
-
-SUNSET LICENSE
-Version 1.0, June 2017
-
-1. You may copy, modify, use, sell, or distribute this work, verbatim or
-modified, for any purpose.
-
-2. If you sell or distribute this work, whether verbatim or modified, you must
-include a copy of this license, and you must make the source code available for
-no extra charge.
-
-3. A modified version of this work must be clearly labeled as such.
-
-4. Derivative works must also be licensed under this license or a license of
-equivalent terms. As an exception, linking this work with another, whether
-statically or dynamically, does not impose any license requirements on the
-other work.
-
-5. If a minimum of 15 years have passed since the date of first publishing for
-a part of this work, then that part is placed into the public domain and you
-may do whatever you want with it, regardless of all other clauses.
-
-
- -

The git repository also contains an accompanying rationale and a simple logo I threw together. In -the future, all my projects will either use this license or the Unlicense. Works I've already -created will be relicensed as appropriate.

-{% endblock -%} - - diff --git a/project/templates/sunset.xhtml b/project/templates/sunset.xhtml new file mode 100644 index 0000000..ab4389d --- /dev/null +++ b/project/templates/sunset.xhtml @@ -0,0 +1,63 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Sunset License{%- endblock -%} + + + +{%- block content %} +

Sunset License

+ +

Git repository: Link

+ +
29/6/2017
+ +

Software licenses bother me. As a general rule I prefer to make my projects open source, +and for that purpose something like the Unlicense + is often sufficient. But if I don't want to put my work in the public domain immediately, then +I have to make use of a copyleft license. +And all of the ones currently available are both incredibly, unnecessarily verbose, and fail to +address the primary failing of modern copyright law, which is the unreasonably long term lengths. +

+ +

So after a considerable amount of thought, I've written my own. (I can hear those with legal +knowledge wailing and gnashing their teeth already.) Care has been taken to mimic the phrasing used +in popular existing licenses where possible. I've also kept it as simple and as straightforward as I +can make it. So hopefully there are no loopholes and it's exactly as it appears: a simple weak +copyleft license which places older parts of a work under a public domain disclaimer in a reasonable +timeframe.

+ +

The full text is as follows:

+
+
+SUNSET LICENSE
+Version 1.0, June 2017
+
+1. You may copy, modify, use, sell, or distribute this work, verbatim or
+modified, for any purpose.
+
+2. If you sell or distribute this work, whether verbatim or modified, you must
+include a copy of this license, and you must make the source code available for
+no extra charge.
+
+3. A modified version of this work must be clearly labeled as such.
+
+4. Derivative works must also be licensed under this license or a license of
+equivalent terms. As an exception, linking this work with another, whether
+statically or dynamically, does not impose any license requirements on the
+other work.
+
+5. If a minimum of 15 years have passed since the date of first publishing for
+a part of this work, then that part is placed into the public domain and you
+may do whatever you want with it, regardless of all other clauses.
+
+
+ +

The git repository also contains an accompanying rationale and a simple logo I threw together. In +the future, all my projects will either use this license or the Unlicense. Works I've already +created will be relicensed as appropriate.

+{% endblock -%} + + diff --git a/project/templates/sydneyrail.html b/project/templates/sydneyrail.html deleted file mode 100644 index a2959cf..0000000 --- a/project/templates/sydneyrail.html +++ /dev/null @@ -1,160 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Sydney Rail Maps{%- endblock -%} - - - -{%- block content %} -

Sydney Rail Maps

- -

Git repository: Link

- -
21/9/2021
- - -
Overview
- -

Over the years there have been more than a few railway network maps created for Sydney, -Australia. All sorts of official, -unofficial, hypothetical, geographical, and historical ones can be found via a -websearch with your favourite search engine. This is my contribution to that -pile of pictures.

- -
- - Hypothetical Sydney rail map - -
A hypothetical Sydney heavy rail map
-
- -

The above map represents a lot of proposals actually implemented and opportunities taken instead -of missed. The map was constructed as a 3000x2800 SVG, but due to rendering consistency issues it -has been exported into PNG format here. Click it to open a full scale version. Since emphasis is on -a "what if" for heavy rail lines, no grid, index, light rail, or other transport services have been -included.

- - -
Line Differences and Notes
- -

There are 12 lines depicted, including 6 suburban double deck, 5 metro single deck, and 1 -suspension monorail. For the most part the colour of preexisting lines has been made consistent with -recent official maps.

- -

Suburban lines:

- - - -

Metro lines:

- - - -

Monorail lines:

- -

Despite everything else this may be the most controversial idea here. In the past Sydney had a -very poorly designed, low capacity monorail loop -between the CBD and Pyrmont. What is proposed here is much closer to monorail systems found in -countries like Japan and China where monorails are constructed to provide services like a heavy -rail line. The technology would be a modified SAFEGE system to allow for 6 car trains and 80km/h -service speed.

- - - - -
Unmapped Features
- -

The Southern / Inner West, Airport / East Hills, and Cumberland lines all overlap track, as do -the Northern and Strathfield lines. All other lines use their own dedicated track pairs exclusively. -This means the hypothetical network is made up of 9 independent sectors overall.

- -

Despite the above, there is some overlap with intercity services. Southern Highlands services -would operate via Glenfield, Wolli Creek, and Sydenham, which makes up for the lack of express East -Hills services from Campbelltown. Central Coast services would still operate via Hornsby, Epping, -Strathfield. In both cases minor interference between sectors is possible.

- -

Other modes of transport have been intentionally left out. This includes an extensive -hypothetical light rail network covering the eastern suburbs, as well as the CBD, parts of the inner -west, and a few lines around Parramatta. There is also potential for important bus rapid transit -services between the North Shore and Northern Beaches, as well as one around Liverpool.

- -

Finally, there are three options for extending public transport to the second Sydney airport at -Badgerys Creek. The Airport / East Hills line could be extended, the Carlingford monorail could be -extended, or a new branch of the Western line could be constructed from St Marys as in current -official maps. In the long term all three options may be ideal. The current proposal of the solitary -St Marys branch may have the unacceptable downside of overcrowding on the Western line.

- - -
Closing Remarks
- -

It is interesting how increased connectivity in a transit network leaves less and less room for -the distortions necessary for the clean schematic lines expected of such maps.

- -

At some point I would like to go back and make a map that includes some of the mentioned unmapped -features. Although at that point it may be more practical to use computational routing methods.

-{% endblock -%} - - diff --git a/project/templates/sydneyrail.xhtml b/project/templates/sydneyrail.xhtml new file mode 100644 index 0000000..c5873e2 --- /dev/null +++ b/project/templates/sydneyrail.xhtml @@ -0,0 +1,160 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Sydney Rail Maps{%- endblock -%} + + + +{%- block content %} +

Sydney Rail Maps

+ +

Git repository: Link

+ +
21/9/2021
+ + +
Overview
+ +

Over the years there have been more than a few railway network maps created for Sydney, +Australia. All sorts of official, +unofficial, hypothetical, geographical, and historical ones can be found via a +websearch with your favourite search engine. This is my contribution to that +pile of pictures.

+ +
+ + Hypothetical Sydney rail map + +
A hypothetical Sydney heavy rail map
+
+ +

The above map represents a lot of proposals actually implemented and opportunities taken instead +of missed. The map was constructed as a 3000x2800 SVG, but due to rendering consistency issues it +has been exported into PNG format here. Click it to open a full scale version. Since emphasis is on +a "what if" for heavy rail lines, no grid, index, light rail, or other transport services have been +included.

+ + +
Line Differences and Notes
+ +

There are 12 lines depicted, including 6 suburban double deck, 5 metro single deck, and 1 +suspension monorail. For the most part the colour of preexisting lines has been made consistent with +recent official maps.

+ +

Suburban lines:

+ + + +

Metro lines:

+ + + +

Monorail lines:

+ +

Despite everything else this may be the most controversial idea here. In the past Sydney had a +very poorly designed, low capacity monorail loop +between the CBD and Pyrmont. What is proposed here is much closer to monorail systems found in +countries like Japan and China where monorails are constructed to provide services like a heavy +rail line. The technology would be a modified SAFEGE system to allow for 6 car trains and 80km/h +service speed.

+ + + + +
Unmapped Features
+ +

The Southern / Inner West, Airport / East Hills, and Cumberland lines all overlap track, as do +the Northern and Strathfield lines. All other lines use their own dedicated track pairs exclusively. +This means the hypothetical network is made up of 9 independent sectors overall.

+ +

Despite the above, there is some overlap with intercity services. Southern Highlands services +would operate via Glenfield, Wolli Creek, and Sydenham, which makes up for the lack of express East +Hills services from Campbelltown. Central Coast services would still operate via Hornsby, Epping, +Strathfield. In both cases minor interference between sectors is possible.

+ +

Other modes of transport have been intentionally left out. This includes an extensive +hypothetical light rail network covering the eastern suburbs, as well as the CBD, parts of the inner +west, and a few lines around Parramatta. There is also potential for important bus rapid transit +services between the North Shore and Northern Beaches, as well as one around Liverpool.

+ +

Finally, there are three options for extending public transport to the second Sydney airport at +Badgerys Creek. The Airport / East Hills line could be extended, the Carlingford monorail could be +extended, or a new branch of the Western line could be constructed from St Marys as in current +official maps. In the long term all three options may be ideal. The current proposal of the solitary +St Marys branch may have the unacceptable downside of overcrowding on the Western line.

+ + +
Closing Remarks
+ +

It is interesting how increased connectivity in a transit network leaves less and less room for +the distortions necessary for the clean schematic lines expected of such maps.

+ +

At some point I would like to go back and make a map that includes some of the mentioned unmapped +features. Although at that point it may be more practical to use computational routing methods.

+{% endblock -%} + + diff --git a/project/templates/tags.html b/project/templates/tags.html deleted file mode 100644 index be63920..0000000 --- a/project/templates/tags.html +++ /dev/null @@ -1,34 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Tags{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

Tags

- - -{% endblock -%} - - diff --git a/project/templates/tags.xhtml b/project/templates/tags.xhtml new file mode 100644 index 0000000..42f3b5a --- /dev/null +++ b/project/templates/tags.xhtml @@ -0,0 +1,34 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Tags{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

Tags

+ + +{% endblock -%} + + diff --git a/project/templates/tags/application.html b/project/templates/tags/application.html deleted file mode 100644 index f1b4b60..0000000 --- a/project/templates/tags/application.html +++ /dev/null @@ -1,32 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Application Tag{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

Tag: Application

- - -{% endblock -%} - - diff --git a/project/templates/tags/application.xhtml b/project/templates/tags/application.xhtml new file mode 100644 index 0000000..e8555c7 --- /dev/null +++ b/project/templates/tags/application.xhtml @@ -0,0 +1,32 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Application Tag{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

Tag: Application

+ + +{% endblock -%} + + diff --git a/project/templates/tags/binding.html b/project/templates/tags/binding.html deleted file mode 100644 index 222ded4..0000000 --- a/project/templates/tags/binding.html +++ /dev/null @@ -1,32 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Binding Tag{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

Tag: Binding

- - -{% endblock -%} - - diff --git a/project/templates/tags/binding.xhtml b/project/templates/tags/binding.xhtml new file mode 100644 index 0000000..34d5b91 --- /dev/null +++ b/project/templates/tags/binding.xhtml @@ -0,0 +1,32 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Binding Tag{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

Tag: Binding

+ + +{% endblock -%} + + diff --git a/project/templates/tags/compsci.html b/project/templates/tags/compsci.html deleted file mode 100644 index 7b9f5b1..0000000 --- a/project/templates/tags/compsci.html +++ /dev/null @@ -1,32 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Compsci Tag{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

Tag: Compsci

- - -{% endblock -%} - - diff --git a/project/templates/tags/compsci.xhtml b/project/templates/tags/compsci.xhtml new file mode 100644 index 0000000..7a269ef --- /dev/null +++ b/project/templates/tags/compsci.xhtml @@ -0,0 +1,32 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Compsci Tag{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

Tag: Compsci

+ + +{% endblock -%} + + diff --git a/project/templates/tags/copyright.html b/project/templates/tags/copyright.html deleted file mode 100644 index 686b025..0000000 --- a/project/templates/tags/copyright.html +++ /dev/null @@ -1,32 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Copyright Tag{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

Tag: Copyright

- - -{% endblock -%} - - diff --git a/project/templates/tags/copyright.xhtml b/project/templates/tags/copyright.xhtml new file mode 100644 index 0000000..9c23058 --- /dev/null +++ b/project/templates/tags/copyright.xhtml @@ -0,0 +1,32 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Copyright Tag{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

Tag: Copyright

+ + +{% endblock -%} + + diff --git a/project/templates/tags/esoteric.html b/project/templates/tags/esoteric.html deleted file mode 100644 index 223c57c..0000000 --- a/project/templates/tags/esoteric.html +++ /dev/null @@ -1,32 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Esoteric Tag{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

Tag: Esoteric

- - -{% endblock -%} - - diff --git a/project/templates/tags/esoteric.xhtml b/project/templates/tags/esoteric.xhtml new file mode 100644 index 0000000..14f75b4 --- /dev/null +++ b/project/templates/tags/esoteric.xhtml @@ -0,0 +1,32 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Esoteric Tag{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

Tag: Esoteric

+ + +{% endblock -%} + + diff --git a/project/templates/tags/language.html b/project/templates/tags/language.html deleted file mode 100644 index a7730b8..0000000 --- a/project/templates/tags/language.html +++ /dev/null @@ -1,32 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Language Tag{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

Tag: Language

- - -{% endblock -%} - - diff --git a/project/templates/tags/language.xhtml b/project/templates/tags/language.xhtml new file mode 100644 index 0000000..f3193ca --- /dev/null +++ b/project/templates/tags/language.xhtml @@ -0,0 +1,32 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Language Tag{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

Tag: Language

+ + +{% endblock -%} + + diff --git a/project/templates/tags/legal.html b/project/templates/tags/legal.html deleted file mode 100644 index ff8b9d9..0000000 --- a/project/templates/tags/legal.html +++ /dev/null @@ -1,32 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Legal Tag{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

Tag: Legal

- - -{% endblock -%} - - diff --git a/project/templates/tags/legal.xhtml b/project/templates/tags/legal.xhtml new file mode 100644 index 0000000..71e30dd --- /dev/null +++ b/project/templates/tags/legal.xhtml @@ -0,0 +1,32 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Legal Tag{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

Tag: Legal

+ + +{% endblock -%} + + diff --git a/project/templates/tags/library.html b/project/templates/tags/library.html deleted file mode 100644 index dd2dc62..0000000 --- a/project/templates/tags/library.html +++ /dev/null @@ -1,32 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Library Tag{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

Tag: Library

- - -{% endblock -%} - - diff --git a/project/templates/tags/library.xhtml b/project/templates/tags/library.xhtml new file mode 100644 index 0000000..b73f7b5 --- /dev/null +++ b/project/templates/tags/library.xhtml @@ -0,0 +1,32 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Library Tag{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

Tag: Library

+ + +{% endblock -%} + + diff --git a/project/templates/tags/maps.html b/project/templates/tags/maps.html deleted file mode 100644 index 745c49e..0000000 --- a/project/templates/tags/maps.html +++ /dev/null @@ -1,32 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Maps Tag{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

Tag: Maps

- - -{% endblock -%} - - diff --git a/project/templates/tags/maps.xhtml b/project/templates/tags/maps.xhtml new file mode 100644 index 0000000..ccccc34 --- /dev/null +++ b/project/templates/tags/maps.xhtml @@ -0,0 +1,32 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Maps Tag{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

Tag: Maps

+ + +{% endblock -%} + + diff --git a/project/templates/tags/mathematics.html b/project/templates/tags/mathematics.html deleted file mode 100644 index b39967d..0000000 --- a/project/templates/tags/mathematics.html +++ /dev/null @@ -1,32 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Mathematics Tag{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

Tag: Mathematics

- - -{% endblock -%} - - diff --git a/project/templates/tags/mathematics.xhtml b/project/templates/tags/mathematics.xhtml new file mode 100644 index 0000000..6d16264 --- /dev/null +++ b/project/templates/tags/mathematics.xhtml @@ -0,0 +1,32 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Mathematics Tag{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

Tag: Mathematics

+ + +{% endblock -%} + + diff --git a/project/templates/tags/politics.html b/project/templates/tags/politics.html deleted file mode 100644 index 414ea98..0000000 --- a/project/templates/tags/politics.html +++ /dev/null @@ -1,32 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Politics Tag{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

Tag: Politics

- - -{% endblock -%} - - diff --git a/project/templates/tags/politics.xhtml b/project/templates/tags/politics.xhtml new file mode 100644 index 0000000..8b2b1f9 --- /dev/null +++ b/project/templates/tags/politics.xhtml @@ -0,0 +1,32 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Politics Tag{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

Tag: Politics

+ + +{% endblock -%} + + diff --git a/project/templates/tags/programming.html b/project/templates/tags/programming.html deleted file mode 100644 index 4c7d83c..0000000 --- a/project/templates/tags/programming.html +++ /dev/null @@ -1,32 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Programming Tag{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

Tag: Programming

- - -{% endblock -%} - - diff --git a/project/templates/tags/programming.xhtml b/project/templates/tags/programming.xhtml new file mode 100644 index 0000000..8307d65 --- /dev/null +++ b/project/templates/tags/programming.xhtml @@ -0,0 +1,32 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Programming Tag{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

Tag: Programming

+ + +{% endblock -%} + + diff --git a/project/templates/tags/transport.html b/project/templates/tags/transport.html deleted file mode 100644 index 863da30..0000000 --- a/project/templates/tags/transport.html +++ /dev/null @@ -1,32 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Transport Tag{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

Tag: Transport

- - -{% endblock -%} - - diff --git a/project/templates/tags/transport.xhtml b/project/templates/tags/transport.xhtml new file mode 100644 index 0000000..b457d92 --- /dev/null +++ b/project/templates/tags/transport.xhtml @@ -0,0 +1,32 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Transport Tag{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

Tag: Transport

+ + +{% endblock -%} + + diff --git a/project/templates/tags/videogames.html b/project/templates/tags/videogames.html deleted file mode 100644 index 904aa29..0000000 --- a/project/templates/tags/videogames.html +++ /dev/null @@ -1,32 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Videogames Tag{%- endblock -%} - - - -{%- block style %} - -{% endblock -%} - - - -{%- block content %} -

Tag: Videogames

- - -{% endblock -%} - - diff --git a/project/templates/tags/videogames.xhtml b/project/templates/tags/videogames.xhtml new file mode 100644 index 0000000..188f016 --- /dev/null +++ b/project/templates/tags/videogames.xhtml @@ -0,0 +1,32 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Videogames Tag{%- endblock -%} + + + +{%- block style %} + +{% endblock -%} + + + +{%- block content %} +

Tag: Videogames

+ + +{% endblock -%} + + diff --git a/project/templates/thue2a.html b/project/templates/thue2a.html deleted file mode 100644 index 76a1279..0000000 --- a/project/templates/thue2a.html +++ /dev/null @@ -1,105 +0,0 @@ - -{%- extends "base.html" -%} - - - -{%- block title -%}Thue Version 2a{%- endblock -%} - - - -{%- block content %} -

Thue Version 2a

- -

Git repository: Link

- -
1/1/2017
- -

Thue is an esoteric programming -language based on unrestricted grammars. A Thue program consists of a number of rules detailing a -sequence of symbols to replace and a sequence of symbols to replace with, and an initial state of -the program. Applicable rules are then applied to the inital state in a random order until no more -are applicable, at which point the program terminates.

- -

An example Thue program that increments a binary number surrounded by '_' characters:

-
- -1_::=1++ -0_::=1 -01++::=10 -11++::=1++0 -_0::=_ -_1++::=10 -::= -_1111111_ - -
- -

The before and after symbols in each rule are separated by '::=' and the list of rules is ended -by a blank rule. Note that whitespace in rules and the inital state is NOT ignored.

- -

Output is handled by prefixing the right hand side with '~', which causes those symbols to go to -stdout and the replacement in the program to be the empty string.

- -

The traditional Hello World program:

-
- -a::=~Hello World! -::= -a - -
- -

Input is handled by having the right hand side of a rule be ':::', which causes the left hand -side symbols to be replaced with a line from the standard output. Unfortunately, this immediately -causes problems.

- -

The following is an innocent piece of code that accepts a single line of input and does nothing -more. Maybe.

-
- -a::=::: -::= -a - -
- -

If a string involving the letter 'a' is entered into the above program, the single input rule -will again become applicable and another line of input will be obtained. In other words, the input -in Thue is unescaped and allows direct code injection into a program.

- -

To solve this problem, I've constructed a slightly modified version of Thue that I'm calling -version 2a. In this version, all symbols obtained through stdin are treated as different from -ordinary symbols. Rules can refer to and manipulate symbols obtained through stdin by surrounding -them in double quotes.

- -

A rule that replaces an ordinary symbol 'a' with 'abc':

-
- -a::=abc - -
- -

A rule that replaces the letter 'a' that was obtained from stdin with 'abc':

-
- -"a"::=abc - -
- -

For convenience, a number of escaped characters are also available:

-
-
-\\ -> backslash
-\r -> return
-\n -> newline
-\: -> colon
-\" -> double quote
-\EOT -> end of file
-
-
- -

While this doesn't solve all the problems Thue has (try writing a Thue program that asks for and -greets the user by name!) it should solve this one particular issue.

-{% endblock -%} - - diff --git a/project/templates/thue2a.xhtml b/project/templates/thue2a.xhtml new file mode 100644 index 0000000..e729280 --- /dev/null +++ b/project/templates/thue2a.xhtml @@ -0,0 +1,105 @@ + +{%- extends "base.xhtml" -%} + + + +{%- block title -%}Thue Version 2a{%- endblock -%} + + + +{%- block content %} +

Thue Version 2a

+ +

Git repository: Link

+ +
1/1/2017
+ +

Thue is an esoteric programming +language based on unrestricted grammars. A Thue program consists of a number of rules detailing a +sequence of symbols to replace and a sequence of symbols to replace with, and an initial state of +the program. Applicable rules are then applied to the inital state in a random order until no more +are applicable, at which point the program terminates.

+ +

An example Thue program that increments a binary number surrounded by '_' characters:

+
+ +1_::=1++ +0_::=1 +01++::=10 +11++::=1++0 +_0::=_ +_1++::=10 +::= +_1111111_ + +
+ +

The before and after symbols in each rule are separated by '::=' and the list of rules is ended +by a blank rule. Note that whitespace in rules and the inital state is NOT ignored.

+ +

Output is handled by prefixing the right hand side with '~', which causes those symbols to go to +stdout and the replacement in the program to be the empty string.

+ +

The traditional Hello World program:

+
+ +a::=~Hello World! +::= +a + +
+ +

Input is handled by having the right hand side of a rule be ':::', which causes the left hand +side symbols to be replaced with a line from the standard output. Unfortunately, this immediately +causes problems.

+ +

The following is an innocent piece of code that accepts a single line of input and does nothing +more. Maybe.

+
+ +a::=::: +::= +a + +
+ +

If a string involving the letter 'a' is entered into the above program, the single input rule +will again become applicable and another line of input will be obtained. In other words, the input +in Thue is unescaped and allows direct code injection into a program.

+ +

To solve this problem, I've constructed a slightly modified version of Thue that I'm calling +version 2a. In this version, all symbols obtained through stdin are treated as different from +ordinary symbols. Rules can refer to and manipulate symbols obtained through stdin by surrounding +them in double quotes.

+ +

A rule that replaces an ordinary symbol 'a' with 'abc':

+
+ +a::=abc + +
+ +

A rule that replaces the letter 'a' that was obtained from stdin with 'abc':

+
+ +"a"::=abc + +
+ +

For convenience, a number of escaped characters are also available:

+
+
+\\ -> backslash
+\r -> return
+\n -> newline
+\: -> colon
+\" -> double quote
+\EOT -> end of file
+
+
+ +

While this doesn't solve all the problems Thue has (try writing a Thue program that asks for and +greets the user by name!) it should solve this one particular issue.

+{% endblock -%} + + -- cgit