adopt tuple-based leapjoin API

It turned out that the old dyn-based API didn't mesh well, so remove it.
The tuple-based API also enables `filter_with` and `filter_anti` to be
used on their own, though perhaps a dedicated loop would be more
efficient in that case.

Author: nikomatsakis

src/lib.rs

@@ -27,7 +27,7 @@ pub use crate::treefrog::{
     filter_anti::FilterAnti,
     filter_with::FilterWith,
     filters::{PrefixFilter, ValueFilter},
-    Leaper, RelationLeaper,
+    Leaper, Leapers, RelationLeaper,
 };
 
 /// A static, ordered list of key-value pairs.
@@ -116,9 +116,9 @@ impl<Tuple: Ord> Relation<Tuple> {
 
     /// Creates a `Relation` using the `leapjoin` logic;
     /// see [`Variable::leapjoin`]
-    pub fn from_leapjoin<'a, SourceTuple: Ord, Val: Ord + 'a>(
+    pub fn from_leapjoin<'leap, SourceTuple: Ord, Val: Ord + 'leap>(
         source: &Relation<SourceTuple>,
-        leapers: &mut [&mut dyn Leaper<'a, SourceTuple, Val>],
+        leapers: impl Leapers<'leap, SourceTuple, Val>,
         logic: impl FnMut(&SourceTuple, &Val) -> Tuple,
     ) -> Self {
         treefrog::leapjoin(&source.elements, leapers, logic)
@@ -409,8 +409,9 @@ impl<Tuple: Ord> Variable<Tuple> {
     ///   some dynamic variable `source` of source tuples (`SourceTuple`)
     ///   with some set of values (of type `Val`).
     /// - You provide these values by combining `source` with a set of leapers
-    ///   `leapers`, each of which is derived from a fixed relation. You can create
-    ///   a leaper in one of two ways:
+    ///   `leapers`, each of which is derived from a fixed relation. The `leapers`
+    ///   should be either a single leaper (of suitable type) or else a tuple of leapers.
+    ///   You can create a leaper in one of two ways:
     ///   - Extension: In this case, you have a relation of type `(K, Val)` for some
     ///     type `K`. You provide a closure that maps from `SourceTuple` to the key
     ///     `K`. If you use `relation.extend_with`, then any `Val` values the
@@ -423,10 +424,10 @@ impl<Tuple: Ord> Variable<Tuple> {
     /// - Finally, you get a callback `logic` that accepts each `(SourceTuple, Val)`
     ///   that was successfully joined (and not filtered) and which maps to the
     ///   type of this variable.
-    pub fn from_leapjoin<'a, SourceTuple: Ord, Val: Ord + 'a>(
+    pub fn from_leapjoin<'leap, SourceTuple: Ord, Val: Ord + 'leap>(
         &self,
         source: &Variable<SourceTuple>,
-        leapers: &mut [&mut dyn Leaper<'a, SourceTuple, Val>],
+        leapers: impl Leapers<'leap, SourceTuple, Val>,
         logic: impl FnMut(&SourceTuple, &Val) -> Tuple,
     ) {
         self.insert(treefrog::leapjoin(&source.recent.borrow(), leapers, logic));

src/test.rs

@@ -61,7 +61,7 @@ fn reachable_with_leapfrog(edges: &[(u32, u32)]) -> Relation<(u32, u32)> {
         // reachable(N1, N3) :- edges(N1, N2), reachable(N2, N3).
         reachable.from_leapjoin(
             &reachable,
-            &mut [&mut edges_by_successor.extend_with(|&(n2, _)| n2)],
+            edges_by_successor.extend_with(|&(n2, _)| n2),
             |&(_, n3), &n1| (n1, n3),
         );
     }
@@ -125,6 +125,46 @@ proptest! {
         let output2 = sum_join_via_relation(&set1, &set2);
         assert_eq!(output1.elements, output2.elements);
     }
+
+    /// Test the behavior of `filter_anti` used on its own in a
+    /// leapjoin -- effectively it becomes an "intersection"
+    /// operation.
+    #[test]
+    fn filter_with_on_its_own((set1, set2) in (inputs(), inputs())) {
+        let input1: Relation<(u32, u32)> = set1.iter().collect();
+        let input2: Relation<(u32, u32)> = set2.iter().collect();
+        let intersection1 = Relation::from_leapjoin(
+            &input1,
+            input2.filter_with(|&tuple| tuple),
+            |&tuple, &()| tuple,
+        );
+
+        let intersection2: Relation<(u32, u32)> = input1.elements.iter()
+            .filter(|t| input2.elements.binary_search(&t).is_ok())
+            .collect();
+
+        assert_eq!(intersection1.elements, intersection2.elements);
+    }
+
+    /// Test the behavior of `filter_anti` used on its own in a
+    /// leapjoin -- effectively it becomes a "set minus" operation.
+    #[test]
+    fn filter_anti_on_its_own((set1, set2) in (inputs(), inputs())) {
+        let input1: Relation<(u32, u32)> = set1.iter().collect();
+        let input2: Relation<(u32, u32)> = set2.iter().collect();
+
+        let difference1 = Relation::from_leapjoin(
+            &input1,
+            input2.filter_anti(|&tuple| tuple),
+            |&tuple, &()| tuple,
+        );
+
+        let difference2: Relation<(u32, u32)> = input1.elements.iter()
+            .filter(|t| input2.elements.binary_search(&t).is_err())
+            .collect();
+
+        assert_eq!(difference1.elements, difference2.elements);
+    }
 }
 
 /// Test that `from_leapjoin` matches against the tuples from an
@@ -144,7 +184,7 @@ fn leapjoin_from_extend() {
     while iteration.changed() {
         variable.from_leapjoin(
             &variable,
-            &mut [&mut doubles.extend_with(|&(i, _)| i)],
+            doubles.extend_with(|&(i, _)| i),
             |&(i, _), &j| (i, j),
         );
     }