Proposal for HKT restructuring

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:

https://github.com/mikearnaldi/hkt-new

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 S invariant, R contravariant, etc.

[mikearnaldi]

A side effect of this would be that Deno will be working (without tracing and plugins) https://github.com/Effect-TS/core/issues/754 given the main issues was usage of module augmentation

[mikearnaldi]

@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)