Nr 2 was solved by recent ts versions and 3 is a problem with type inference in ts in general (eg: I have similar issues w fp-ts)
Nr 1 can be avoided as long as you don't use the ts equivalent of rank n types (which seems like a fair cost for the simplicity of the implementation)
But fp-ts does it the long way, so what do I know
Nr 1 can be avoided as long as you don't use the ts equivalent of rank n types (which seems like a fair cost for the simplicity of the implementation).
If that is your objective yes, you can probably simplify it further.
In that encoding I still don't find how to make transformers work like: github.com/Matechs-Garage/matechs-...
Personally I prefer making the low level implementation complex (as it does not target user-land code) and provide more features that works smoothly.
Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink.
Hide child comments as well
Confirm
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nr 2 was solved by recent ts versions and 3 is a problem with type inference in ts in general (eg: I have similar issues w fp-ts)
Nr 1 can be avoided as long as you don't use the ts equivalent of rank n types (which seems like a fair cost for the simplicity of the implementation)
But fp-ts does it the long way, so what do I know
Nr 1 can be avoided as long as you don't use the ts equivalent of rank n types (which seems like a fair cost for the simplicity of the implementation).
If that is your objective yes, you can probably simplify it further.
In that encoding I still don't find how to make transformers work like:
github.com/Matechs-Garage/matechs-...
Personally I prefer making the low level implementation complex (as it does not target user-land code) and provide more features that works smoothly.