Repository navigation
Implement Predicate<T> #98
Description
many times I ended up in writing following combinators, I think it would add some value if library has it :
- F<A, Bool> and(F<A, Bool> pred1, F<A, Bool> pred2)
- F<A, Bool> or(F<A, Bool> pred1, F<A, Bool> pred2)
- F < B, Bool > comap(F<B, A>, F<A, Bool>)
- F<B, Bool> notFor(F<B, A>, F<A, Bool>) [a la Haskell's Data.Function.Predicate's
isn't] - F<A, Bool> inverse(F<A, Bool>)
additionally we could add:
nand, nor, xor
We can also implement Predicate2<A, B>, Predicate3<A, B, C> and so on.
thoughts?
Activity
mperry commentedon Jan 28, 2015
I think we need these, the closest thing I can see is in the Booleans class (e.g.
Booleans.not), so perhaps that is the best place to add these.Personally, I don't think we need a Predicate class and related arities. Given Java uses nominative typing I think conversion is a pain and would have few advantages.
I would encourage you to do this and submit a pull request.
amarpotghan commentedon Jan 28, 2015
Now as I see through
Booleans, definitely we don't need Predicates.techtangents commentedon Jan 28, 2015
I would also advise against a Predicate type. We had one in our fj
equivalent, and removed it. It was just a hassle, and no benefit over
simply writing F<A, Boolean>.
The 'and', 'or' etc functions for F<A, Boolean> are reasonable, though.
F<A, Boolean> forms 2 Moniods, one over 'and', one over 'or'. The 'or'
variant is also an Alternative.
F<A, Boolean> or(List<F<A, Boolean>> fs) {...}
F<A, Boolean> and(List<F<A, Boolean>> fs) {...}
amarpotghan commentedon Jan 30, 2015
@techtangents every function F<A, B> should form a monoid if B is monoid. Is my understanding correct?
techtangents commentedon Jan 30, 2015
Sounds right to me.
mperry commentedon Feb 7, 2015
This is addressed in PR #102.