Note that this calls out to a generated type function (the writer) for which we
do not yet generate a definition. So far this looks like a pretty reasonable
approach though.

They can now be referenced in e.g. assignment statements.

Note, these are not yet registered in the symbol table so you cannot yet
reference them.

More consistent.

This makes for a cleaner class hierarchy where we catch at compile time when
we're trying to use something as an lvalue that can never actually serve as one.

It didn't seem like this alias abstraction was gaining us anything and it was
becoming a bit of a problem when it needed to sometimes represent a
SimpleTypeExpr and sometimes an aggregate.

There are still some unresolved issues we'll have to tackle here. In particular,
 - lvalues of simple typed variables that are contained in aggregate types
 - rvalues/lvalues of ExprIDs
 - discriminate TypeExprID between a simple and aggregate reference

We may actually want to remove this in future once things stabilise and there
are certain nodes that do not need it. For now though, it seems more flexible to
just make it available to all nodes.

It didn't previously occur to me that these need to be wrapped too.

We'll need to toggle this when we have support for local variables.

It would be nice to get to a point where the checker builds with -W -Wall
-Wextra in the presence of all sane models.

This might seem like a bit of an odd direction to go in. However, I've realised
the advantages we get from C++ in the checker are actually not especially
significant. The main strengths in code like this are being able to write static
code ahead of time using templates and then instantiate it during generation.
However, we need to emit custom classes for almost everything non-trivial (e.g.
records).

None of the data structures we need are especially complex, except the state set
and queue which I think we're best outsourcing. My hypothesis is that this
combination (C source + GLib) can beat a C++ solution, in terms of runtime and
memory usage. I don't know whether this will pan out, but interesting to try.

One notable thing we lost in this change was exception support. Exceptions were
shaping up to be quite an elegant mechanism for reporting a checker failure.
However, my long term plan was always to remove them (or at least make them
optional) to allow better interoperability with other languages. I think we
should probably still be able to come up with a performance, thread-safe
solution.

This is essentially the complete algorithm. We now simply need to implement the
generation of rule bodies.

Note that we convert some state values to pointers in this change. I think this
will be necessary once we start tracking previous pointers.

The checker is now buildable, though it doesn't do anything.

It constantly irritates me (and presumably other C/C++ programmers) that '==' is
not the comparison operator. There's no ambiguity in introducing it, so let's
just accept it as an alias for '='.

Accidental result of refactoring.

Well that was unexpected.