Terminology

[skeate]

I feel like we need to discuss the terminology used.

My understanding is:

• "Schemable" is a typeclass; "a schemable" is a thing with an instance of that typeclass. For example, Eq is "a schemable". Equivalently, Eq implements Schemable or, most verbosely, Eq permits a Schemable instance.
• A "Schema" for a type T (plural schemata) is a thing that can be interpreted with a schemable to produce a value of the schemable for type T. For example, interpreting a Schema for Foo with Eq yields a Eq<Foo>
  • A Schema that takes other schemata as arguments is a "schema combinator" (though, when those arguments are actually applied, the result is just a "schema" again.)

I think those two are pretty clear and I think we've all been using the same terminology for them.

Where I'm unsure are:

• WithX things. What are they? They aren't Schemables. I've been thinking of them as "schemable extensions" but if we eventually move to a more dynamic model where what a Schema needs depends on what is inside of it, then it's not necessarily an extension anymore. E.g. if we have a Schema that only depends on pattern then it only needs to be interpreted with a WithPattern instance.
  They are typeclasses, yes, but I think we need something a bit more specific since we can't create a schema based on (say) a Witherable
• Somewhat related, what do we call the individual things inside Schemable or the WithX things? e.g. lowercase int. I guess, since Schemable and WithX things are both typeclasses, these would be methods?

Since the unifying characteristic of all these things is that they can be used to interpret a Schema, I am tempted to propose "interpretable" but to me that sounds more like a synonym for a Schema. Instead of being able to be interpreted, it is the means by which it is interpreted. By analogy to spoken language interpreters:

• What a person says ~= Schema
• The actual interpreter ~= interpret
• The interpreter's understanding of the target's language ~= Schemable/WithX

[jacob-alford]

When I've been referring to the WithFoo's, I've been thinking of them as Schemables - short for "Schemable Extensions." Thinking about the word Schemable, it seems to me like "something that can be modeled by a schema," and implies that Eq, Guard, etc are the real schemables. Instead, what if we start to think about Schemable being a common generating interface among Typeclasses (like Eq, Guard, etc)? And so in that framework we can decide to break it apart into a base collection of methods Schemable, and a collection of extensions: Schemable Extensions which we can abbreviate to Schemables.

I also recently referred to (in the above framework) the implementation of a Schemable for a Typeclass (I'll just call them Schemable Typeclasses) as Interpreters. I think this is wrong, an interpreter is just a function: Schema -> Schemable Typeclass.

So to recap:

• Schemable: A collection of combinator methods that are intended to form some Typeclass
• Schemable Extensions (Schemables for short): a collection of extensions to Schemable
• Schemable Typeclass: A typeclass which contains (or permits) an implementation of every Schemable Extension*
• Interpreter: A function from Schema to Schemable Typeclass to Typeclass
• Schema: A function from Schemable Typeclass to Typeclass
• Schemata: A collection of functional combinators that form a Schema

On point three* With doesn't really make sense if the intention is to define Schemable Typeclass implementations for every Schemable Extension, so for version 2 it might make sense to drop the With moniker. Likewise it might also make sense to rethink the idea of schema to be some generic reader, and not associated with Schemable. In which case, maybe With still makes sense.

On this topic, I also want to discuss not adopting the new schema system of fp-ts/schema and keeping this lovely schemable system around. Looking at it, a Provider is a less type-safe variation of a Schemable Typeclass. It has some benefits that every Schemable Typeclass has an attached Schema, which means that Schema can't contain details about the type it produces. I think there's novelty in this, but I'd prefer a type safe version. And the upside to a typesafe version is that you don't have to rely on an unsafe implementation and throwing if a provider is missing a schematic key (e.g. String's Symbol.for) or if a schematic key is missing a provider key (e.g. Decoder's Symbol.for).

If we decide not to adopt the unsafe Provider schema system of fp-ts/schema, we can still port io-ts's implementations and adjust the definitions for Decoder / etc to be in line with fp-ts/schema so the generated typeclasses are compatible between the two libraries. This would make schemata-ts feel rich and complete on its own.

[skeate]

All for not doing this Provider thing. Honestly find it a bit perplexing. Seems very unextendible.

[skeate]

Honestly we might want to ditch the io-ts dependency and just copy what we need from it into this library. I have a feeling we might need to, anyway; if fp-ts/schema becomes the io-ts replacement in the new fp-ts ecosystem then I imagine io-ts will be not well maintained

[jacob-alford]

Agreed! That was part of the plan with the base instances re-exporting from io-ts

[jacob-alford]

And we can also define our own Schemable, no more SchemableExt business

[skeate]

Schemable is itself the typeclass, though. An analogy -- Functor : Schemable :: ReadonlyArray.Functor : Decoder.Schemable

Eq, Decoder etc are data types that admit Schemable instances.

[skeate]

(not a serious suggestion. ... at least not yet)

[jacob-alford]

I suppose we can technically describe it as a polymorphic typeclass parameterized by data kind

[jacob-alford]

I feel like that could go in the readme: Schemable is an example of an open typeclass family, which is simply a polymorphic typeclass parametrized by kind

[jacob-alford]

Also this article is so relevant, and also hilariously esoteric

https://www.parsonsmatt.org/2017/04/26/basic_type_level_programming_in_haskell.html

[jacob-alford]

Rabbit hole continued:

https://www.haskell.org/ghc/docs/7.8.4/html/users_guide/kind-polymorphism.html

[jacob-alford]

What about renaming Schemable Typeclasses (decoder, encoder, etc) to "Derivations?" This will make it easier to distinguish between schemable extensions, which we can just call schemables.

[jacob-alford]

And we can put the derivations (that are created with the generate script) into their own folder src/derivations, and the base instance will be available to export the getFoo function and will also be available to export derivation specific helpers/combinators

[skeate]

I like it