GitLab

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

Fields in these structs are now named.  Embedding is reserved for
things that are very explicitly supposed to carry their methods along.

At some earlier point, I embedded the Type field in some of the
generate structs because it saved me a few keystrokes in refactoring
template strings.  This was not important.

Today I learned: if you have embeddings which cause a name to be
shadowed -- as the generateKindedRejections_String.Type field
could shadow the generateKindString.Type field, for example -- if those
resolve "neutrally" (I don't know if there's a better technical term
for this), then... in that case, the templating system will be like
"yeah, fine, whatev", and it works.  If you give one of those two
fields a *separate type*, the templating system will now reject it as
if no field of that name can be found.

I encountered this while working on the generator for structs (which I
*swear* I will commit any second now, when I stop finding prerequisite
yaks to shave -- there have been many) and trying to use a more
specialized TypeStruct instead of the Type interface.  Whee.

I get the logic of this.  The error message could be better.

Anyway: even though it technically didn't affect generateString (yet),
making the change here for consistency with what's to come
(including specializing the field even though there's currently no
actual need for it).

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 wanted this for use in codegen work: in particular, as part of
generating error messages.

Note the comment on the case for unions.  I still go back and forth on
this topic; see some recent previous commit messages on this branch.
(I think I'm slowing coming around to "unions act like maps", and it's
just that most library code chooses to jump over them transparently,
because that's the least-odd path for resolving NodeBuilder questions;
but it remains the case that none of this is settled for sure yet.)

The Go Playground is also often a perfectly good home for these things;
I've also used "_rsrch" directories in other projects, especially if
benchmarks of nontrivial runtime and setup get involved; but this
will suffice for this quick factcheck here and now.

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.

The schema.Type objects don't have a `Kind() ReprKind` method.  That
was just a bad idea.  I didn't try to fix it; I just nuked it.

The new schema.Type.Kind() method docs include a description of why
it's incorrect to wish for a either a single or a statically known
ReprKind for a type.

(Context mention: the previous commit was also a wind-up for this.
And technically, I'm still winding back up the mental stack here:
this had to get straightened out because I wanted to start poking
codegen for structs; and then I had beef with the TypeStruct.tupleStyle
field being a bool; and then fixing that pointed out that the current
Type.ReprKind methods were kinda insane... yaks!)

Comments added addressing some of the root issues of why, and how to
try again more correctly next time.  (At least one open question
has been found that might take a few days to resolve.)

This commit happens now because they code being removed refered to
`schema.Type.ReprKind()` a lot, and that's the real issue I'm focused
on at the moment -- that's also going away in the next commit or so.
There's significantly more subtlety to the type-vs-representation
duality than the existence of such a method could accurately describe.

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>

Generating these tiny thunks seems much cheaper than expanding the
exported surface of our most essential package.

Exercise unmarshal against our generated "Strang" type.  Works!

(Note: this will fail if you *haven't* run the codegen yet; but it's in
an underscore-prefixed package, so it won't run unless you dive in here
intentionally.  Overall, this continues to be early-days hijinx, and
does not represent a good long-term testing strategy.)

The generated package now compiles completely happily.  Neat.

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

typed.Node.Representation(), which returns another Node, should address
most of the infelicies we've found so far in trying to plan nice code
that works over the schema layer.

Also added in this comment: ipld.ReprKindSet, primarily for use in the
ErrWrongKind error.  It comes up often enough we might as well formalize
the thing.

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>

- `typed.Node` -> now lives in the `impl/typed` package, more like
other nodes.

- Most of the other essential parts of reasoning about types moved
to `schema` package.  ("typed.Type" seemed like a nasty stutter.)

- `typed.Universe` renamed to `schema.TypeSystem`.

- Current `Validate` method moved to `schema` package, but see new
comments about potential future homes of that code, and its
aspirational relationship to `typed.Node`.

Conspicuously *not* yet refactored or moved in this comment:

- The `typed/declaration` package -- though it will shortly be scrapped
and later reappear as `schema/ast`.  The dream is that it would be
neatest of all if we could generate it by codegen; but we'll see.
(This would seem to imply we'll have to make sufficient exported
methods for creating the `schema.Type` values... while we also want
to make those immutable.  We'll... see.)

- The `typed/gen` package is also untouched in this commit, but
should similarly move shortly.  The codegen really ought to be built
against the `schema.Type` reified interfaces.

Overall, this drops the sheer nesting depths of packages a fair bit,
which seems likely to be a good smell.