John's
amb operator has a weakness: it is satisfied with finding one successful value. What if we want all the solutions?
We must invent a related operator. Let us call it kanzen, Japanese for completion/perfection (完全). (This is not the "kan" in "kanren" which is 関連).
amb-scope and amb are defined exactly as before, but we add:
(defun kanzen (. args)
(suspend amb-scope cont
(return-from amb-scope
(append-each ((a args))
(whenlet ((res (and a (call cont a))))
(list res))))))
Using only
amb, let's find some pair of integers x y, in the range 0 to 9, whose product is 12:
(prinl
(amb-scope
(let ((x (amb 0 1 2 3 4 5 6 7 8 9))
(y (amb 0 1 2 3 4 5 6 7 8 9)))
(amb (eql (* x y) 12))
(list x y))))
The output is:
(2 6)
Now, let's change the first
amb to
kanzen. Just the first one:
(prinl
(amb-scope
(let ((x (kanzen 0 1 2 3 4 5 6 7 8 9))
(y (amb 0 1 2 3 4 5 6 7 8 9)))
(amb (eql (* x y) 12))
(list x y))))
The output now is:
((2 6) (3 4) (4 3) (6 2))
all the (x y) pairs are found that multiply to 12.
What does kanzen do differently? Like amb, it cares only about non-nil arguments. However, instead of just finding the first non-nil argument for which the future computation succeeds (returns non-nil), and then returning that result out of amb-scope, kanzen probes all non-nil arguments. It continues the future computation with each value, and for each computation that succeeds (returns non-nil), it collects that value into a list. Then it aborts amb-scope using that list as the result value.
So the weird thing to be understood here is that (list x y) doesn't necessarily determine the ultimate result value of the amb-scope form. The first amb or kanzen call holds the reins, so to speak. If the first operator is amb then, indeed, the result value will be one that was produced by (list x y). amb will try the different futures, and when it finds one that yields non-nil, it aborts amb-scope with that value.
What happens with kanzen is that the ((y (amb ...))) part will find successful y values, and abort amb-scope. But it's doing that aborting within the scope of a continuation created by kanzen, so kanzen intercepts that, collects the (list x y) value, and keeps trying other futures. Thus, confusingly, the result doesn't have shape expected by (list x y).
Note how this is fundamentally hostile to static typing. This code depends on exactly the same piece of syntax, the amb-scope block, having a different type in different contexts: a list of integers during the execution of the search, and a list of lists of integers in the ultimate return.
A static typing theory could be developed for this which assigns multiple types to a node in the program. The interior of amb-scope can see its return value as "pair of integers". all the continuations captured within that scope have that return type. But because of the presence of kanzen, the node can be assigned an external static type as "list of pairs of integers". Or something like that.