# Threaded queries? Rulebase independence?

**URL:** <https://swi-prolog.discourse.group/t/threaded-queries-rulebase-independence/1236>\
**Category:** Help!\
**Created:** [September 11, 2019, 11:27pm UTC](https://swi-prolog.discourse.group/t/threaded-queries-rulebase-independence/1236 "2019-09-11T23:27:13Z")\
**Posts on this page:** 1\
**Showing post:** 23

<div class="post-metadata">

**Author:** ![jan](https://yyz2.discourse-cdn.com/free1/user_avatar/swi-prolog.discourse.group/jan/32/4_2.png) [@jan](https://swi-prolog.discourse.group/u/jan)\
**Post date:** [May 6, 2020, 7:07am UTC](https://swi-prolog.discourse.group/t/threaded-queries-rulebase-independence/1236/23 "2020-05-06T07:07:17Z")

</div>

> [@pmoura](#):
>
> % call fact/1 in “self”

Yes. a clean solution requires some _self_ notion. Logtalk has that by design. In plain (SWI-)Prolog you have some options, roughly:

- (Mis)use meta predicates. Problem is that this indeed requires a lot of book keeping, although it isn’t that hard to automate that.
- Use the SWI-Prolog stack introspection to get some goal on the stack from which we can derive _self_. This is fairly simple to program and “not so bad”. Can be a little slow if the stacks are deep. It is still a design pattern for which I at some plan want better (means faster and cheaper) support.
- Notably for this case, where the combination of a thread and a module are used, put the _self_ in a global variable, so you get

```prolog
    nb_getval(self, Self),
    Self:fact(X).

```

---

_[View the full topic](https://swi-prolog.discourse.group/t/threaded-queries-rulebase-independence/1236)._