An interesting category of functionality in prolog is their dynamic function framework. They are a generalization of databases and allow to do matching in a scalable manner through indexing. Guile log also support a full indexer for a simplified matcher. And for all matched clauses they will be executed in order acording to how the database is setuped. One can add clauses to the head or to the end, remove clauses according to a pattern and also store states for later rewinding. The state guarding mechanism is either cheap (weak) e.g. it will not remember states as long as the action is above in the stack, else if it backtracks below the stack, state will be stored and restored at reentrence. We also support strong state storage at e.g. postpone support.
To use the api use
(use-modules (logic guile-log functional-database)).
SCM (define-dynamic f), this will make a dynamic function object and bind it to
G.L. (<push-dynamic> f lambda-dyn), push a match onto the head of dynamic function
lambda-dyn is a special lambda typically created through,
SCM (<lambda-dyn> pat ... code), here
pat ... will be simplified patterns only supporting
quote,unquote all else directive is not allowed.
code is evaluated in guile-log mode.
Similarly we can add code to the end of the dynamic function, e.g.
G.L. (<append-dynamic> f lambda-dyn).
Also to remove elements one can use,
G.L. (<remove-dynamic> (f a ...)), where
f is the dynamic function and
a ... the patterns for the arguments that, which matches will be retracted.
The previous set of API is typically what you get to use in prolog. The downside is that they posses problem w.r.t. leaking data and therefor the next ideom is preferable to use in order to make sure both that one undo any changes to the dynamic variable, but also at reinstation of a state inside the form, it will resore to the same state as when control left the inner of the ideom e.g. The design is to favor fast lookup and adding and removing information is a bit expensive.
G.L. (<with-dynamic-functions> (f ...) code ...), for this form
f ..., will be weakly guarded throughout the form e.g. if control leaves the form then the state is stored if needed and at reinstation of state inside
code ..., the old state of the dynamic variable will be reinstated. But inside the form state of the dynamic functions is not saved or restored.
A stronger form of guard can be used in case one would like to make sure that the dynamic functions state can be reinstated in case of e.g. postpone is used, then use,
G.L. (<guard-dynamic-functions> (f ...) code ...),
Finally the last section conserns the ability to compile the dynamic function for as fast lookup as possible, use
G.L. (<dynamic-compile> f ...), comiles the dynamic functions
f ... for fast lookup. This ideom takes time and if used freely can cause a high memory consumption.