hkts VS static-land

We need to be able to parse incoming json/xml/etc into typescript types. This is done or doable with the hkts decoder which is a partial port of io-ts.

Before diving into the nitty gritty of how hkts implements higher kinded types, how hkts handles type-class constructor lengths, or how one might implement Monad for These, I will begin at the end. This is to say, I will be starting with examples of how to use Option, Either, Task, and more. Then I will endeavor to explain what type classes like Functor, Monad, Traverse, and Monoid mean. Lastly, I'll get into the typescript abstractions that make hkts possible.

There are respective fantasy land and static land specs, with the law conformance checks.

A big poster child of functional style in JS-land is actually implemented on top of textbook OOP (Array.prototype.map/filter). For anyone interested in the gore details of functional polymorphism, look no further than the comparison between fantasy land and static land. Basically, it boils down to a simple fact: functional algebra constructs can be implemented in terms of other functional algebra constructs, but when push comes to shove, the most efficient Array map implementation is not going to be the same thing as a map implementation for any other data structure (Stream, Optional, whatever) and you can't have a magical compiler optimize under the hood for you in Javascript, because well, Javascript. So functional polymorphism has to be shoved somewhere, and as it turns out OOP happens to be a good complement for that conundrum.

My goal with hkts is two-fold. First, to learn more about functional programming by implementing some common type classes (specifically, the ones defined in the static-land spec). Second, to put together a pragmatic, easy to read/understand library of tools based on fp-ts, io-ts, and monocle-ts that are deno native.