Better encoding for HKTs
Feature request
Current Behavior
Currently, we're using declaration merging and type level defunctionalization to simulate HKTs. They did their job well, but there was fundamental problem.
They're too verbose to use!
When we define some data type that's constructor is HKT, we need to define URI for it and extend proper URItoKind interface by declaration merging. this is not only boring work but also producing unreadable code.
https://github.com/gcanti/fp-ts/blob/e708323cfcff0b4e013ecf6f90a00816fb943a64/src/Option.ts#L51-L65
This is not only problem about data types, but also type classes. Actually, It's even worse in case of type classes.
Why those things happens? Well, IMHO, I think this problem has been caused from two property of current way of encoding HKTs.
- HKTs are separated based on their number of type parameters.
So we must write definition for all HKTs separately, by using something like function overloading(which makes code long, and verbose), instead of writing definition at once.
- It's based on declaration merging & defunctionalization
Fundamental idea of current way of simulating HKTs is to express direct reference to HKTs by indirect reference(by using URI & URItoKind). As well as we choose to go around, it's natural to be suffered from boilerplate codes.
Desired Behavior
What I want is simpler & easier & readable encoding of HKTs. And to break down current limitation of this way of encoding HKTs(ex: It's hard to write HKTs that takes HKTs)
This will make this library more practical.
Suggested Solution
I've found some interesting trick that could be used to encoding HKTs,
How about using this trick to encoding HKTs? Indeed we need more research and investigations about this(ex: is this safe to use?, is there any limitation?, is there better way of using this trick? what else this trick can do?) but I think discussing about this would be valuable.
Who does this impact? Who is this for?
All of fp-ts users.
Additional context
- another example of using this trick - Generating eliminator for given constraint in typescript
- It seems to define kind system(or something like that) is possible with this trick.
- We can even use this trick to define type families!(and whenever self-appointed circular conditional type become stable, we can do whatever we wanted so far)
Source: gcanti/fp-ts