support or-parallelism

[mndrix]

Create a new ChoicePoint implementation which, in a separate goroutine, steps a machine until it fails or finds an answer. It then sends itself down a channel where the original machine can extract its "future self" if it follows that disjunction.

We'll need some timing information to know which predicates are worth spawning. Once we have that, we can choose which choice points want parallel execution and which don't.

During this process, keep an eye open for ways to support and-parallelism too.

[jerluc]

@mndrix is this a way to perform speculative execution of sorts in order to optimize in the case that one of the or-predicates can quickly be determined to be true?

[mndrix]

@jerluc Yup, that's exactly right. As with all speculative execution, there are some details to work out surrounding IO. We don't want to speculatively launch any missiles.

[jerluc]

Got it. Also, just to call out, outside of I/O and other side-effects of that nature that require in-order semantics around AND/OR evaluation, another interesting case is that of recursion. As a trivial example:

fac(0, 1).
fac(A, B) :- 
      A > 0, 
      Ax is A - 1,
      fac(Ax, Bx), 
      B is A * Bx.

In the above scenario, depending on how the function guards are implemented in your interpreter, you would not want to speculatively recurse down the fac(A, B) route if fac(0, 1) is true, as this would obviously lead to some fun infinite recursion :)