Here's the first iteration to adapt the library to different contexts with a minimal change in the API.
Please see the tests in ContextSpec.scala.
I don't consider this PR ready for merging yet.
There are a few things where I find myself in need or help, or that are worth discussing:
Kleisli and Profunctor integration (for the moment they are commented out).
RuleApplicativelaws testing. Currently commented out. If uncommented, some implicit(s) are missing. Without delving further into laws testing, I'm currently unable to sort this out.
Due to their new shapes, I am currently falling short of finding a satisfactory way of letting Rule1.field (and .fieldWith) take a 2nd Rule1 as an implicit parameter. Everything works fine with an explicit 2nd Rule1.
I added a Rule1.and method. The difference with andThen is that it requires the Rule1s to be just Applicative instead of Monad. This makes it possible to run the rules in parallel whenever their context's Applicatives define parallel execution (as is the case of, say, Future). However, it is not right to define this for every Rule1, since a Rule1 can return the same type as the input, but another value. I think we actually need a subclass of Rule1 (which I would call Check) whose semantics indicate that it's a Rule1 that always returns the same value as the input. (Rule.test would return Check). Combining Checks with and results in a Check, and they can be combined with other Rules by using andThen (resulting in a Rule). For the moment Check is just a Rule1.
Here's the first iteration to adapt the library to different contexts with a minimal change in the API.
Please see the tests in
ContextSpec.scala.I don't consider this PR ready for merging yet.
There are a few things where I find myself in need or help, or that are worth discussing:
RuleApplicativelawstesting. Currently commented out. If uncommented, some implicit(s) are missing. Without delving further into laws testing, I'm currently unable to sort this out.Rule1.field(and.fieldWith) take a 2ndRule1as animplicitparameter. Everything works fine with an explicit 2ndRule1.Rule1.andmethod. The difference withandThenis that it requires theRule1s to be justApplicativeinstead ofMonad. This makes it possible to run the rules in parallel whenever their context'sApplicatives define parallel execution (as is the case of, say,Future). However, it is not right to define this for everyRule1, since aRule1can return the same type as the input, but another value. I think we actually need a subclass ofRule1(which I would callCheck) whose semantics indicate that it's aRule1that always returns the same value as the input. (Rule.testwould returnCheck). CombiningChecks withandresults in aCheck, and they can be combined with otherRules by usingandThen(resulting in aRule). For the momentCheckis just aRule1.