GitLab

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

Giving a type to each, um, kind of type.

Syntax draft changed.  Bigger examples elsewhere.  May need to start
writing up more, but might not belong in this repo, either (it's not
a detail of the golang implementation alone).  Anyway, it's only for
eyecandy at present: I'm not going to start work on a parser for the
DSL any time soon; it's just something to keep in mind so it can be
evaluated against simplicity heuristics.

Struct fields are in a slice now.

Waffling on whether to call that kind "struct" vs "object".  Neither is
very satisfying.  "Struct" is suggestive of something with concrete
memory layout considerings; this is not that.  "Object" is suggestive
of something with methods and behaviors attached; this is not that.

Introduce an enum for different kinds of union.  Some of the terms here
are developed from https://github.com/ipfs/unixfs-v2/issues/20 ; the
term "keyed" is from https://github.com/polydawn/refmt/pull/30 ; and
the style "kinded" is a concept I haven't written up much about before,
but the TypeUnion.ValuesKinded field type should self-explain it.

Flip terminology from "required" to "optional".  Struct fields that are
mentioned in the schema default to being required; why else would you
have mentioned them?  Previous draft of DSL which used question marks
and exclamations points to denote these things dropped; the new hope is
that *neither* nullable nor optional will be used with enough frequency
that the sigil-heavy shorthand will turn out to be desirable.
Signed-off-by: Eric Myhre <hash@exultant.us>

The very first draft tried to get away with *one* "Kind" enumeration,
but that quickly became odd and shakey; *two* separate "Kind" enums
(one for the Data Model, one for the lower level Representation;
working terms, and mine) fits a lot better.  The latter is what we're
committing here.

Also of interest here is a proposal for a distinction between whether
fields are *required* vs *nullable*.  I'm not sure this has been done
before in any of the other systems I've examined so far; it's a concept
I think we'll want for dealing with the subtle distinction between
whether some piece of data *matches* our schema vs whether it's *valid*
within our schema.  But it's quite hypothetical; it's possible this
whole concept of "matching" will turn out a lot more complex than that.

There's a tossed out syntax for a schema DSL in a comment.  This is
utterly unscrutinized and should not be taken too seriously yet.

The example code at the bottom declaring some type system is code that
*could* be used, but is mostly for demonstration and early dev
purposes: in the long run, we *do* want to come up with a DSL, and all
the relevant grammers, parsers, and so on for using that as an
implementation-agnostic source of truth.  At that (far future) point,
this kind of code would be used internally to represent what's been
parsed out of the DSL; but users shouldn't really be writing it.
(That's a long-winded way of saying "yes, some parts of that code are
extremely not DRY and would be error prone if written manually"; and
indeed, they would, and thus the point is not to.)
Signed-off-by: Eric Myhre <hash@exultant.us>