Potential schema-schema changes.

[warpfork]

This is going to be a "draft" PR for discussion -- if anything comes of it, it'll probably be done by breaking out smaller diffs after discussion.

These are some potential changes to the schema-schema that I've developed while exercising things over in https://github.com/ipld/go-ipld-prime/pull/76 .

• All the unions are now keyed. Previously TypeDefn and TypeDefnInline were using "inline" representation. This results in most of the diff (it changes the indentation of quite a few things).

  • This seems desirable because keyed unions are the thing that we generally recommend the most highly be default (because in turn they're the most parser-friendly).
  • It was also awfully convenient for the sake of development over in the aforementioned PR, because we have codegen implemented for keyed union representations, but not for inline representations. (Not a reason that'll endure, but kind of interesting to note, because this also has a reason in turn: the support for keyed unions is much, much easier to write than that for inline representations (and we might expect this to be noticed by other implementers of these systems in new languages in the future).)

• There's now a "Unit" type in play. The definition of this can be approximated by an empty struct -- the semantic is that it must have a cardinality of one. We need to add this concept to the schema system. (I think I've mentioned this elsewhere, but if not, now it's mentioned!)

  • I've referred to it, but haven't actually added this type to the diff, because I think we may want to add a "unit" kind and also a "Unit" type to the "prelude" (i.e. just like "String" is in the "prelude" and always means type String string).

• Enums are specified using the 'Unit' type. Which means serially, they now have {} inside them instead of null. This might be a temporary change: it's a consequence of the idea to emulate Unit by use of an empty struct, and if we give "unit" its own kind, we could give it its own selection of representation strategies (which could then include a choice of a representation like "null").

  • Previously, enums internally had an allusion to a "Null" type, which was also not defined in the schema-schema, so clarifying this to into Unit is the same or better as before, and addressing the Unit-related todos will make it entirely proper.
  • This also means I was able to actually parse the dang thing, over in my implementation PR, by indeed using a dummy declaration of Unit to be an empty struct.

There are also some renames which I felt improved clarity:

• Type -> TypeDefn
• InlineDefn -> TypeDefnInline
• TypeTerm -> TypeNameOrInlineDefn

I haven't altered the schema-schema DSL file to match yet. That diff would be quite a bit smaller (since it wouldn't have the indent change effect from the switch of union representation).

[warpfork]

@rvagg I'll be particularly interested in your thoughts on this. I think we've discussed some of these changes before, but now they're drafted to be seen in full. What are our impressions?

[rvagg]

Maybe we need to chat about this real-time. I'm probably not going to block these changes, but the removal of "kind" is a little annoying, it means you have to fish around inside the map for a list of keys, one of which will presumably tell you what it is, no more switch (thing.kind) {}. I think I've mentioned my hesitation about Unit when you raised it before too. It seems like a very Go-thinking concept that has dubious utility in here outside of Go codegen (which is not entirely unreasonable, but let's attempt to be a little balanced). I'd like to see a clearer justification for requiring an additional thing to handle this case. It would be good if you could cook up definitions for TypeUnit and whatever else you need to represent it.

[vmx]

(it's not really related to the topic, but might be useful though, GitHub supports diffs without whitespace only changes: https://github.com/ipld/specs/pull/291/files?diff=split&w=1)

[warpfork]

Unit actually comes from more of a haskelly view than a Golang view, fwiw. It's not common thinking in the Go world at all. :) Wikipedia's Unit type article is also good.

But point taken, I do need to write about it a bit more fully somewhere.

EDIT: that is now in https://github.com/ipld/specs/issues/292

[warpfork]

... I'm going to turn this into a merge-ignore, because I want the content for future reference, but I'm not working on this right now and will not push it to completion (and not necessarily in this exact form) anytime in the immediately coming days.

We'll see a "merge" here in the github UI shortly, but it will be a product of git checkout master && git merge -s ours this-branch, which means the content diff will not be taking actual effect on master.

[warpfork]

...ah, or not, because I pushed the merge before pushing the rebase I also did. Well, whatever. Closing, then. Same difference from the git POV, which I care about a great deal more than the github view.

[warpfork]

(Much of this, though not all, and also many other things, happened, in https://github.com/ipld/ipld/pull/136 .)