GitLab

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>

(These have been on my working copy for *months*, waiting to get some
sliver of time to get back to working on this half of the project...)

So, back in the last time period I was working on schemas, it seemed
plausible to try to get some self-bootstrapping amount of codegen to
help me write the whole declaration package itself.  This has not
held up, lol.

The long end of line comment is my updated feelings about this:
the main reason self-hosting even during bootstrap would've been nice
is for map order consistency.  But... we don't... need that.  Per se.

This commit will be merge-ignored momentarily; gonna pick up on
schema work again starting from a somewhat different angle of attack.
Signed-off-by: Eric Myhre <hash@exultant.us>

Signed-off-by: Eric Myhre <hash@exultant.us>

I'm using templates for this rather than AST libraries because after
some review of existing systems, it seems that this is a popular
choice; and I'm flat out going to assume those people have known
what they were doing and made their choice rationally.  Protobufs,
graphql codegen libraries, the ugorji serialization libraries -- almost
every codegen I've ever come across uses templating.  So, we will too.

And so far, the results seem promising.

The tests here will be shoddy for some time.  I'm outputting code to
a directory and periodically eyeballing it and making sure the compiler
likes it.  My aim is to get some fair fraction of codegen bootstrapped
this way; and after we start codegen'ing the typedeclaration package
itself, *then* we'll start solidifying things with regression tests.

There's a lot of discovery process to go, here.  See for example the
comments about ranging versus iterators (namely, that it's not
possible, which... turns out is going to feed back into our design
all the way back out at the layer of the ipld.Node interface itself).
Signed-off-by: Eric Myhre <hash@exultant.us>