GitLab

This isn't a net negative size diff yet, but it certainly will have
that effect momentarily when we add a generator for another kind.
More importantly, it reduces the set of functions in the real
generator file to *just* the relevant ones.

We'll almost certainly extend this to cover the NodeBuilder half of
things as well, later; I just haven't gotten there yet.

I'm solving the decorum problem by making "temporary" builder methods for the
schema.Type values as necessary.  This will allow the gengo package to use
them freely for now.  When we're done with all this, I want to restrict building
of schema.Type values to a single method in the schema package which takes the
"ast" types -- the ones we're hoping to codegen (!) -- and do lots of checks
and cross-linking; the temporary builder methods will do *none*, and *of course*
they can't take the "ast" types yet since they don't exist yet.

Boom, cycle broken.

Also: fix generateStringKind from taking a TypeName redundantly.

This was triggered by an experiment about generating even more 'minima'
like this, such as a batch of helper structs which would hold all the
common "no, you can't do operation X on something of kind Y" methods.
However, that diff isn't here; and is probably going to turn out to be
abandoned, because after trying it out, I found that it was pretty hard
to do good error messages (which... was pretty central to the point)
with that approach.  So, more on those attempts later.
Signed-off-by: Eric Myhre <hash@exultant.us>

The generated package now compiles completely happily.  Neat.

What was left in this last file was mostly docs; and while some of
that text might be good, we can either write it fresh or come
dredge it out of history when we re-build something like this package.

Fix the few remaining references to declaration by switching them
to refer to the reified equivalents in the schema package (which is
what all those references should have been anyway).
Signed-off-by: Eric Myhre <hash@exultant.us>

Dropped older PoC/draft codegen code at the same time; that
was a stale idea and the draft that followed it is already
clearly shaping up better.
Signed-off-by: Eric Myhre <hash@exultant.us>

The underscore makes it ignored by the go tools;
the gitignore does, well, git.

At some point this should probably grow up to have more complete
tooling and test suites around it, but for early iteration,
I pretty much have one window open to the generated output file,
and I'm just running it to see if it compiles, and while this probably
won't last for long, it's enough to get exploratory work done.

The previous code was lots of switches; I think it's safe enough to
say that wasn't going to scale or compose very easily.
This new take is based on some interfaces and a wee dusting of
polymorphism.

The abstraction *won't* hold: we'll drill through it in many places,
and there will still be type switches up the wazoo by the end -- see
the comments already scattered about regarding maps and enums and such.
But that's okay; a few interfaces will still help; at the very least
it makes things a bit more structurally self-documenting.

Strings (and one particular representation and node implementation of
them) are all that's included here, but so far so good.

The comment above, and the one in the code about "triple cross
product", probably waggle towards what's going to be the trickiest
part of this: codegen needs to take into account a *lot* of choices.
Making the code for this maintainable is going to be nontrivial!
Signed-off-by: Eric Myhre <hash@exultant.us>