For any function
f :: Eff es ~> Eff (es' ++ es)
we can have an alternative version of
f_ :: Suffix es es' => Eff es ~> Eff es'
that can work in many places without explicitly annotating types. However, the downside is that once inference fails, the type errors are harder to read and supplying type arguments is also harder.
There are 3 kinds of combinators in cleff:
- Trivial handling combinators
- Interpretation combinators
- HO unlifting combinators
Only class (3) cannot be chained and therefore are safe to use the inference-friendly versions as default. Class (2) is very often chained but not class (1) or (3); in fact class (3) couldn't possibly be chained, and only very bizarre scenarios will require chaining class (1). Therefore the expected changes are:
- Add
interpret_, interpose_, replace_ as inference-friendly versions of existing functions
- Change the signature of HO combinators
toEff, toEffWith and withFromEff to be inference-friendly
- Change the signatures of
raise and subsume to be inference friendly, renaming the original versions to be raise1 and subsume1
This will be a breaking change (though minimal breakage expected), and will hopefully come after another two three minor revisions (#17, #19, #21).
For any function
we can have an alternative version of
that can work in many places without explicitly annotating types. However, the downside is that once inference fails, the type errors are harder to read and supplying type arguments is also harder.
There are 3 kinds of combinators in
cleff:Only class (3) cannot be chained and therefore are safe to use the inference-friendly versions as default.Class (2) is very often chained but not class (1) or (3); in fact class (3) couldn't possibly be chained, and only very bizarre scenarios will require chaining class (1). Therefore the expected changes are:interpret_,interpose_,replace_as inference-friendly versions of existing functionstoEff,toEffWithandwithFromEffto be inference-friendlyraiseandsubsumeto be inference friendly, renaming the original versions to beraise1andsubsume1This will be a breaking change (though minimal breakage expected), and will hopefully come after another
twothree minor revisions (#17, #19, #21).