This PR introduces refactors that simplify readability, and will also make it easier to transition ASTs to kind (* -> *) -> (* -> *). This entails:

• generate f :: * -> * parameters for the record types, in TH, and add them to the generated datatype
• fix the Traversable, Foldable, and Functor instances to account for the new kindedness
• ensure that the children of each record types are wrapped in an f (except for the ann field)
• define some Error functor isomorphic to Either String
• manually define applicative instance for Error type
• add unit tests
• use Error type in Unmarshal

Why is this important?

This addresses #480, #481, #482.

TL;DR: it's a byproduct of having strongly-typed trees, where we can't take advantage of historic polymorphic-ness of our nodes and use Error types everywhere.

@patrickt explained this to me using the following example. Consider a data type like this which looks like the ALC syntax:

data Plus a = Plus { ann :: a, left :: Expression a, right :: Expression a }

That type is polymorphic in its annotation type a, but its children are monomorphic. They are always Expression values. And if we get a parse error from tree-sitter, we can’t construct an Expression. Under a-la-carte syntax, all the children of a node were polymorphic, so we were able just to stick an Error node in there. But our types are stronger now, so we can’t get away with just stuffing Errors everywhere. Instead, what we’re gonna generate is this:

data Plus f a = Plus { ann :: a, left :: f (Expression f a), right :: f (Expression f a) }

In this new precise world, Plus has kind (* -> *) -> * -> * where the first parameter f is a “shape” functor that dictates what possible shapes the children could have. If we start substituting values for f, we get different types of trees. For example,Plus Identity means that left :: Identity (Expression Identity a), right :: Identity (Expression Identity a).

Since Identity a is isomorphic to a, that means Plus Identity is isomorphic to our old definition of Plus.

But what happens when we start getting some more interesting functors? Let’s consider Plus (Either String). Substituting in Either String for f, that leaves us with children that look like left :: Either String (Expression (Either String) a), right :: Either String (Expression (Either String) a) and that lets us handle parse errors. The left field is Right if the parse succeeded and Left if it failed. This means we can slurp a partial or erroneous tree via Unmarshal.

This PR also has a few additional changes that are:

• Cosmetic! 💄 Better readability, reducing repetition and using more expressive functions.
• Standardizing: use the TH function convention instead of data constructors (ie., conT instead of ConT); introducing constructor names in signatures that otherwise had ambiguous types (ex., DatatypeName instead of String).