Let me try to clarify.
I was pointing to the dichotomy in Prolog between the fact base that is considered non-backtrackable (out of the box), and Terms referenced by variables during goal execution, which are by design backtrackable – no need to do anything to make them so.
The backtrackable asserts technique is (merely) a consequence of this design dichotomy – not a means to improve performance.
However, in my work I need backtrackable properties on facts in the fact base.
Currently, the performant way to achieve backtrackable properties on facts, during processing is to thread along a pair of variables a mapping between atoms and their properties – such as through an assoc.
Implicit in this design is that the atom is an argument of a selected predicate, e.g. person(dan), so, its dan the person who gets attributed not necessarily the stand-alone dan atom.
In a language like C such a dichotomy between “static” (fact-base like) and Variable referenced memory, doesn’t exist, hence an atom within the person structure and its property live in the same type of memory space, and the allocated atom can have a pointer to its properties.
Edit:
Perhaps something like this (aligned with the backtrackable variables technique (e.g. [1])):
person(alice).
person(dan).
person(joe).
put_priority(X, Y) :- person(X)&Y0, Y0 <= Y.
get_priority(X, Y), person(X)&Y0, Y0 => Y.
And suppose that & is a distinguished operator to set or get attributes stored with the clauses person(alice), person(dan), etc.
And the operators <= and => set and get the values – all backtrackable.
All this would only make sense if in the course of indexed retrieval of person(X) – the clause, say, person(dan), in memory is located, and getting at the attribute term would then only a pointer hop away.
Dan
p.s. whether clause attributes survive at the end of goal processing might be an option – they could behave like global variables – or could be transient – probably transient is the better (default) option.