Proposal for HKT restructuringSee original GitHub issue
Since the time we implemented HKTs we found a new encoding that doesn’t require having a central registry of URIs and that should have far better performances while allowing for more flexibility.
The encoding is implemented in:
I propose we change the current encoding to reflect the new implementation, as part of the change we will also need to remove the flexibility of choosing the variance of a type parameter namely in the current encoding we are using a config param to specify how a type parameter should be mixed, the problem with that approach is that it may generate inconsistencies, namely we do implementations on a reduced base using
HKT/HKT2 and we have a generic overload that considers all the params with their respective rules but there is no guarantee that the base impl would actually work with that set of rules, namely I could implement a base using R as contravariant and having R as covariant in the target type. Also we actually never used any other setting other than
R contravariant, etc.
- Created 2 years ago
- Comments:10 (1 by maintainers)
Top GitHub Comments
@shroomist yes we are working on a re-unification with
fp-ts that has adopted this encoding for
v3 which is under heavy development by @gcanti, you can follow https://github.com/gcanti/fp-ts/tree/3.0.0-new-hkt for updates. As soon as that is ready
Effect will depend on
fp-ts and provide
fp-ts compliant instances (which is great news for the ecosystem)