Currently, we get:
:- use_module(library(cont)). true. ?- reset(shift(a), X, Y). X = a, Y = none.
However, a shift/1 has occurred, and so Y should be bound to cont(...).
Otherwise, we cannot reliably detect that a shift has occurred.
Please see https://github.com/mthom/scryer-prolog/issues/456#issuecomment-624952769 for a test case.
This could be handled by changing the definition of shift to this:
shift(Ball) :-
'$nextEP'(first, E, P),
get_chunks(E, P, L),
Cont = cont(call_continuation(L)),
'$write_cont_and_term'(_, _, Cont, Ball),
'$unwind_environments'.
I don't think it should lead to problems. call_continuation([]) is completely innocuous.
Yes, I think cont(cont:call_continuation([])) would be good, and cont(true) would be even better.
We need a reliable indicator on when to inspect the term that it passed by shift/1 and obtained in reset/3. The indication for this is that the continuation has the form cont(...). The key point is that this distinction can be made symbolically (sometimes called "by pattern matching", although unification is more general than "matching"), because cont(...) can be cleanly distinguished from none, using argument indexing to make it efficient and also deterministic.
Changing the API in this way would simplify the logic in delim/3 in tabling.pl, making the code more elegant and also faster if indexing is used to distinguish the cases.
I will do PR with cont(true) and adapt tabling.pl with the change.
I will do PR with cont(true) and adapt tabling.pl with the change.
Great, thank you!
Brilliantly solved by @notoria in #468, thank you a lot!