Admit to a draft exploring type systems last week.
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>
Showing
typed/draft.go
0 → 100644
Please register or sign in to comment