add documentation about mixed cycles

book/src/glossary.md

@@ -229,3 +229,15 @@ valuation `A = true, B = false` makes the premise true and the conclusion false.
 ## Valuation
 A valuation is an assignment of values to all variables inside a logical
 formula.
+
+## Fixed-Points
+A fixed-point of a function `f` is a value `x` for which `f(x)=x`.
+Similarly a pre-fixed-point is defined as `x ≤ f(x)`, whereas for a post-fixed-point it holds that `f(x) ≤ x`.
+
+A least fixed-point (lfp) of `f` is the fixed-point `x` of `f` for which all other fixed-points `y` are greater or equal (i.e. if `f(y)=y` then `x ≤ y`).
+Similarly, a greatest fixed-point (gfp) is greater or equal than all other fixed-points.
+If `f` is a function on sets, the least fixed-point is defined as the intersection of all pre-fixed-points, which are then defined as sets `x` for which `x ⊆ f(x)`.
+The greatest fixed-point is in this case the union of all post-fixed-points, respectively.
+
+This simple definition of lfp and gfp can also be lifted to general lattices.
+The results for Chalk goals form such a lattice and, thus, every solver for such goals tries to find such fixed-points.

book/src/recursive/coinduction.md

@@ -2,52 +2,74 @@
 
 This sub-chapter is meant to describe the current handling of coinductive goals in the recursive solver rather than providing an extensive overview over the theoretical backgrounds and ideas.
 It follows the description in [this GitHub comment](https://github.com/rust-lang/chalk/issues/399#issuecomment-643420016) and the Zulip topic linked there.
+In general, coinductive cycles can arise for well-formedness checking and autotraits.
+Therefore, correctly handling coinductive cycles is necessary to model the Rust trait system in its entirety.
 
 ## General Idea
-The general idea for the handling of coinductive cycles in the recursive solver is to start by assuming the goal is provable and then try to find evidence that it is not.
-This search for a disproof is done by the standard recursive solving process described in the sub-chapters before.
+Coinductive cycles can be handled the same way as inductive cycles described [before](./inductive_cycles.md).
+The only difference is the start value for coinductive goals.
+Whereas inductive goals start with a negative result and are iterated until a least fixed-point is found, coinductive goals start with a positive result (i.e. a unique solution with identity substitution).
+This negative result is then iterated until a greatest fixed-point is reached.
 
-Albeit this approach would allow for the handling of mixed inductive/co-inductive cycles, these are actually handled as errors to prevent propagation of the assumed provability outside of the coinductive cycle.
-This propagation of the assumed solution might also happen in pure coinductive cycles and can potentially lead to invalid results.
+## Mixed co-inductive and inductive Cycles
+As described above, the handling of inductive and coindutive cycles differs only in the start value from which the computation begins.
+Thus, it might seem reasonable to have mixed inductive and coinductive cycles as all goals inside these cycles would be handled the same way anyway.
+Unfortunately, this is not possible for the kind of logic that Chalk is based on (i.e. essentially an extension of co-LP for Hereditary Harrop clauses, cf. [this paper][co-LP]).
+
+There is fundamental difference between results for inductive cycles and results for coinductive cycles of goals.
+An inductive goal is provable if and only if there exists a proof for it consisting of a finite chain of derivations from axioms that are members of the least-fixed point of the underlying logic program.
+On the other hand, coinductive goals are provable if there exists an at most infinite derivation starting from the axioms that proves it (this includes in particular all finite derivations).
+This infinite derivation is then part of the greatest fixed-point of the logic program.
+As infinite derivations are not feasible to compute, it is enough to show that such a derivation contains no contradiction.
+
+A simple example `X :- X.` (with `X` a free variable) is thus not provable by inductive reasoning (the least solution/lfp for this is the empty solution, a failure) but it is provable by coinductive reasoning (the greatest solution/gfp is the universe, i.e. all values).
+
+This difference between inductive and coinductive results becomes a problem when combined in a single cycle.
+Consider a coinductive goal `CG` and an inductive goal `IG`. Now consider the simplest possible mixed cycle:
+```notrust
+CG :- IG
+IG :- CG
+```
+It is apparent, that there can not exist a solution for `IG` as the cyclic dependency prevents a finite proof derivation.
+In contrast to that, `CG` could potentially be provable as the derivation *`CG` if `IG` if `CG` if `IG` ...* is infinite and based only on the two axioms.
+As a result, `CG` would hold whereas `IG` would not hold, creating a contradiction.
+
+The simplest solution to this problem, proposed by Simon et al. in [their paper about co-LP][co-LP], is to disallow mixed inductive and coinductive cycles.
+This approach is also used by Chalk.
 
 ## Prevention of Invalid Results
 The problem of invalid results propagated outside of the coinductive cycle is also described in the [Coinduction chapter](../engine/logic/coinduction.md) for the SLG solver alongside the rather complex handling used with it.
+Whereas the SLG solver introduces [special constructs](../engine/logic/coinduction.html#nikos-proposed-solution) to handle coinduction, it is sufficient for the recursive solver to use the same logic for inductive and coinductive cycles.
+The following is a description of how this works in more detail.
 
 ### The Problem
-The problem arises if a solution that is purely based on the positive starting value for the coinductive cycle is cached and as such propagated to other goals that are possibly reliant on this. An example may look like this (cf. the test case `coinduction::coinductive_unsound`):
+The problem arises if a solution that is purely based on the positive starting value for the coinductive cycle is cached (or tabled in logic programming terms) and as such propagated to other goals that are possibly reliant on this. An example where all clause goals are assumedly coinductive may look like this (cf. the test case `coinduction::coinductive_unsound1`):
 
 ```notrust
 C :- C1.
-C :- C2
+C :- C2.
 C1 :- C2, C3.
 C2 :- C1.
 ```
-
-Here `C` may be proved by either showing `C1` or `C2`.
-Assuming the solver starts evaluating the branch with `C1` first, it then recursively tries to prove `C2` and `C3`.
-For proving `C2` it needs to show `C1` again, the coinductive cycle becomes evident.
-Therefore, `C1` is assumed to be provable and the solver proves `C2` with this information.
-Assuming, the solve does not handle this case specifically, the solution for `C2` is cached. 
-Now it tries solving `C3` but fails due to the lack of information about it.
-As such, `C1` can also not be proven for this program.
-The recursive solver will now attempt to prove the initial goal `C` by solving `C2`.
-Unfortunately, it finds the invalidly cached solution and returns it as proof for `C`.
-
-By visualizing this path of computation, it becomes evident, where the problem lies:
-* Start proving `C` with `C1`:
-    * For `C1` prove `C2` and `C3`:
-        * For `C2` prove `C1`:
-            * This is a coinductive cycle. Assume that `C1` holds.
-        * Thus `C2` also holds. Store this result about `C2` in the cache.
-        * There is no way to prove `C3`. Lift this failure up.
-    * Due to the failure of `C3` there is also no solution for `C1`.
-* Try proving `C` with `C2`:
-    * Find the cached result that `C2` has a solution and return it as the solution for `C`.
-* Stop with the invalid result for `C`.
+The following is a computation to find out whether there exists a type that implements `C`.
+Here the implementation of `C` may be proved by either showing that the type implements `C1` or `C2`.
+* Start proving `C` by trying to prove `C1`:
+    * For `C1` try to prove `C2` and `C3`:
+        * Start with `C2`. For `C2` we need to prove `C1`:
+            * This is a (coinductive) cycle. Assume that `C1` holds, i.e. use the positive start value.
+        * Based on this `C2` also holds. If this case is not handled specifically, the solution for `C2` is cached without a reference to the solution for `C1` on which it depends.
+        * Now try to prove `C3`:
+            * Find that there is no way do so from the given axioms.
+        * Thus, there exists no solution for `C3` and the computation fails. This valid result is cached and lifted back up.
+    * Due to the failure of `C3` there is also no solution for `C1`. This failure is also cached correctly and lifted back up. The cached solution for `C2` has now become invalid as it depends on a positive result for `C1`.
+* As a result of the failure for `C1`, `C` can not be proved from `C1`. Try proving `C` from `C2` instead:
+    * Find the cached result that `C2` has a solution and lift it back up.
+* Due to the solution for `C2`, `C` is also proved with the same solution.
+* Stop with this positive but invalid result for `C`.
 
 ### The Solution
 The above example should make it evident that the caching of found solutions in coinductive cycles can lead to invalid results and should therefore be prevented.
-This can be achieved by delaying the caching of all results inside the coinductive cycle until it is clear whether the start of the cycle (i.e. `C1` in the example above) is provable.
+This can be achieved by delaying the caching of all results inside the coinductive cycle until it is clear whether the start of the cycle (i.e. `C1` in the example above) is provable (cf. the handling of inductive cycles [before](./inductive_cycles.md)).
 If the start of the cycle can be proven by the results of the cycle and related subgoals then the assumption about it was correct and thus all results for goals inside the cycle are also valid.
 If, however, the start of the cycle can not be proved, i.e. the initial assumption was false, then a subset of the found solutions for the coinductive cycle may be invalid (i.e. the solution for `C2` in the example).
 
@@ -66,8 +88,11 @@ With this procedure, the example is handled as follows:
         * For `C2` prove `C1`:
             * `C1` has now a negative result.
         * Thus, `C2` also has a negative result which is not yet cached.
-        * The result for `C3` is already cached.
-    * Nothing changed regarding `C1` (this would indicate a negative cycle which is currently  not allowed) and the negative result for `C1` and `C2` are cached. Lift negative result for `C1`.
+        * Find the already cached negative result for `C3`.
+    * Nothing changed regarding `C1` (this would indicate a negative cycle which is currently  not allowed) and the negative result for `C1` and `C2` are cached. Lift the negative result for `C1` back up.
 * Start proving `C` with `C2`:
     * Find negative cached result for `C2`. Lift the result back up.
 * Neither `C1` nor `C2` have a positive result. Stop with the valid disproof of `C`.
+
+
+[co-LP]: https://link.springer.com/chapter/10.1007%2F978-3-540-73420-8_42

book/src/todo.md

@@ -4,4 +4,3 @@ Some topics yet to be written:
 
 - Elaborate on the proof procedure
 - SLG solving – introduce negative reasoning
-- Recursive solver coinduction chapter

chalk-recursive/src/recursive.rs

@@ -212,7 +212,9 @@ impl<'me, I: Interner> SolveDatabase<I> for Solver<'me, I> {
             // Check if this table is still on the stack.
             if let Some(depth) = self.context.search_graph[dfn].stack_depth {
                 self.context.stack[depth].flag_cycle();
-                // Mixed cycles are not allowed.
+                // Mixed cycles are not allowed. For mor information about this
+                // see the corresponding section in the coinduction chapter:
+                // https://rust-lang.github.io/chalk/book/recursive/coinduction.html#mixed-co-inductive-and-inductive-cycles
                 if self
                     .context
                     .stack

chalk-recursive/src/stack.rs

@@ -67,20 +67,18 @@ impl Stack {
         self.entries.pop();
     }
 
-    /// True if either all the goals from the top of the stack down to (and
-    /// including) the given depth are  coinductive or if all goals are inductive
-    /// (i.e. not coinductive).
+    /// True iff there exist at least one coinductive goal
+    /// and one inductive goal each from the top of the stack
+    /// down to (and including) the given depth.
     pub(crate) fn mixed_inductive_coinductive_cycle_from(&self, depth: StackDepth) -> bool {
-        let (inductive, coinductive) =
-            self.entries[depth.depth..]
-                .iter()
-                .fold((false, false), |(ind, coind), entry| {
-                    (
-                        ind || !entry.coinductive_goal,
-                        coind || entry.coinductive_goal,
-                    )
-                });
-        inductive && coinductive
+        let coinductive_count = self.entries[depth.depth..]
+            .iter()
+            .filter(|entry| entry.coinductive_goal)
+            .count();
+        let total_count = self.entries.len() - depth.depth;
+        let any_coinductive = coinductive_count != 0;
+        let any_inductive = coinductive_count != total_count;
+        any_coinductive && any_inductive
     }
 }