Support good type inference with unique parametrized effects #268
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I'm very much dissatisfied with the type inference story for parametrized effects.
It's either thousands of type applications or
effectful-plugin
and I don't particularly like the unnecessary verbosity that comes with the former and the fact that the latter is, well, a GHC plugin and GHC plugins have bugs and usually need to be adjusted for every new GHC version.Considering the fact that if you use an effect with parameters, then in the vast majority of cases there will be only one instance of it you're using at a time, I remembered re-xyr/cleff#23 and managed to package the idea into a nice-looking interface, so now for chosen effects you can do this:
(or write helper functions by hand as usual, just using
<:>
instead of:>
) and it compiles without ambiguity errors.This PR provides helpers for determining all type parameters up to 5, but one can write a local helper class for any combination.
Thoughts about naming?
I thinkNot quite sure aboutTheN
helpers are fine (I thought aboutUniqueN
, but I likeTheN
better).<:>
, though I couldn't come up with anything better.TODO: