Skip to content
This repository has been archived by the owner on Jun 29, 2022. It is now read-only.

schema prelude needs documentation #301

Open
warpfork opened this issue Sep 24, 2020 · 1 comment
Open

schema prelude needs documentation #301

warpfork opened this issue Sep 24, 2020 · 1 comment

Comments

@warpfork
Copy link
Contributor

IPLD Schemas contain a couple of type definitions that are so useful that we don't want to repeat them in each schema. These are declared in something called the "prelude", and can be thought of as implicitly present in the top of every schema.

This set of type definitions is essentially setting a type name for each of the kinds, and creating a concept of Any.

The prelude is this:

type Bool bool
type Int int
type Float float
type String string
type Bytes bytes
type Map {String : nullable Any}
type List [nullable Any]
type Link link
type Any union {
	| Bool   bool
	| Int    int
	| Float  float
	| String string
	| Bytes  bytes
	| Map    map
	| List   list
	| Link   link
} representation kinded

This has (at least) two purposes:

  • Having named types matching each of the scalar kinds means folks can use those type names in the recursive parts of maps and lists and structs and so on, rather than needing to make their own name every time they need one of those kinds. (And also rather than the schema DMT and DSL needing a whole special case for kind names there -- which not just simplifies them, it also makes for simpler higher-level rule for folks writing schemas: field types, map value types, and etc parts of recursive definitions are always a type name: always a capital letter.)

  • The Any type is pretty dang important and useful. It's how a schema can shrug and say "any data nested here is fine, really".

We should have this documentation in general (and can probably largely copy-paste the above into the docs, I suppose), but also there's a couple more things to consider when we put it into pages:

  1. We probably want to associate some recommendations to library authors about how to implement this prelude stuff?
  2. We might need a whole section devoted to Any, and possibly its applications (for example: lots of ADLs that are some kind of container type have an Any field somewhere where they store their contained values). We'll almost certainly need to link to it from other docs pages.
@warpfork
Copy link
Contributor Author

I did indeed find the need to write a separate issue to fully tackle the situation with Any. It's turned out the it's-just-a-kinded-union definition has some implications that (though they might be logically consistent) aren't very user-friendly. The issue for this is #318 .

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant