# Yielding prolog engines from within a foreign predicate

**URL:** <https://swi-prolog.discourse.group/t/yielding-prolog-engines-from-within-a-foreign-predicate/4806>\
**Category:** Help!\
**Tags:** ffi\
**Created:** [December 23, 2021, 6:33pm UTC](https://swi-prolog.discourse.group/t/yielding-prolog-engines-from-within-a-foreign-predicate/4806 "2021-12-23T18:33:11Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![maren](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/maren/32/6605_2.png) [@maren](https://swi-prolog.discourse.group/u/maren)\
**Post date:** [December 27, 2021, 12:44pm UTC](https://swi-prolog.discourse.group/t/yielding-prolog-engines-from-within-a-foreign-predicate/4806/5 "2021-12-27T12:44:30Z")

</div>

I would love to do a PR but studying up on the swipl internals is probably going to take longer than my holiday. But I’ll see what I can do 🙂 .

I wonder if we can’t expand the way nondeterministic predicates work to also allow yielding, as nondets already have a way to pass in a bit of data between calls. All that would be required is some way to differentiate between being called due to needing a next result, or being called because of continuing from a yield. Exploiting the exception mechanism could maybe be used for returning the actual yield term, and the return code could be used to signify that a yield should happen (maybe everything above 256 can be interpreted as a yield code?)  
Also, perhaps predicates that can be expected to yield should be registered somewhat differently, to prevent them from being called from within a context that doesn’t allow yielding.

---

_[View the full topic](https://swi-prolog.discourse.group/t/yielding-prolog-engines-from-within-a-foreign-predicate/4806)._
