Introduce a type theory glossary.

[warpfork]

The goal here is to provide just enough discussion about type theory and the basics of applied state counting that we can establish some language-independent terminology clearly. This should in turn be useful for clarity in conversation, and as a quick link to drop in many other documents that require some foundational concepts, or need to avoid language-specific jargon.

A lot of this exists in literature and theory already... but gathering it in one place, written in one style, in a single page that can be read top to bottom in one sitting... seems to provide value.(Sending someone off on a quest to "read wikipedia and all the related content around concept $X" is great and all, but, ehm. It's a little high latency, a little unreliable in outcome, etc.)

This ended up subsuming and expanding upon the already existing cardinality doc, so that file is deleted; its original content and much more is now in the new file.

This was kicked off in large part by discussion over in https://github.com/ipld/specs/pull/241#discussion_r381942147 , so thanks to @vmx for the good idea and the kick in the shorts to start writing.

Also thanks to @bsundsrud and @batmanaod for some polishing and out-of-band feedback on early drafts, and to @Reasonable-Solutions for some review of the categorical bits, all of which was very helpful.

[rvagg]

Love it, there are some minor things to address in here but let's get it merged.

There's also a section at the bottom of /schemas/schema-kinds.md titled "Understanding Cardinality" that should include a link to here. The pattern in those docs I've taken looks like this:

See [IPLD Schema Kinds](./schema-kinds.md) for more information on this topic.

A link here would be just above the examples. The URL will need to be absolute, to this repo (complete with `https://...), until we get this page published to specs.ipld.io.

[warpfork]

This is a response to a couple of the individual comments on this diff, but I'm gonna post this as a top-level comment for visibility and reference and future discoverability --

I want the "in the wild" sections to be short, pithy triads of examples. I'm not sure I'll generally be favorable towards adding more. The whole document is meant for quick, single-sitting(!) reading, and if the examples start including detailed caveats, variations, opinions, and dozens of languages, then that goal becomes failed.

I picked three languages that give an interesting cross-section. (E.g.: one has enums; one has sum types; one has neither.) They might not be a perfect choice, but I think they're an interesting and illustrative choice.

I didn't pick javascript because there's less of a type system there and more a collection of functions and patterns that sometimes(!) have common naming. I didn't pick lisp for the same reason. It doesn't mean those languages aren't important; I just found it harder to make illustrative comments using them.

I didn't pick haskell because it's actually too good at these concepts; anyone who knows haskell or other similar families of language probably doesn't need this primer. It doesn't mean those languages aren't important; I just found it less useful to make illustrative comments using them.

So, while I appreciate all the comments and reviews and the future PR's I'm sure will come on this topic: there's a good chance my response will be along the lines of "that's true; perhaps it would be interesting if you made a blog about it, or a comparison table in a larger more detailed document somewhere else :)". (And it's a true wish: if you make a writeup like that, accumulating links to those in a "More Information" table in the bottom of this primer will be the best of all readability situations!) Or, if you want to add something to this document: make a PR that adds that language to each example. (If it's coming in as a suggestion for one of the example sets, I don't necessary have enough familiarity to fill in the examples in all the other sets. And it's possible that in doing so, we'll see that the language doesn't provide interesting new perspective on any but one example, which may also change how we want to write about it.)

[warpfork]

Okay... whew...

Rebased and a bunch more things addressed.

Thank you so much for all the comments.

This PR has been daunting me for a while from the sheer volume of them, but I still appreciate it immensely :) I took most of the changes. And at this point I think I also have to leave a few behind, and declare bankruptcy on processing much deeper on this in one thrust. The amount of time that goes into trying to form good, general cross-language statements that can survive examination, much less at arbitrary resolution, is... significant.

Since the general tone feedback seems positive, I'm going to go ahead and merge this now. (I want to start being able to link to it! And github's started doing the "$N hidden conversations" thing 😒, so this PR is definitely long enough that it's getting difficult to manage.) If we've got more refinements to make -- and I'm sure there's plenty of them possible! -- let's do subsequent PRs.

[warpfork]

The URL will need to be absolute, to this repo (complete with `https://...), until we get this page published to specs.ipld.io

Punting on this, btw. I tried, but I couldn't bring myself to do it -- linking to a path that includes github and tree/master just zests my giblets a hair over the line. These links will be broken until we finish renovating the website to fix the whole situation; we should motivate ourselves to do that rather than work around it.