Did you know ... Search Documentation:
Meta-Call Predicates

4.8 Meta-Call Predicates

Meta-call predicates are used to call terms constructed at run time. The basic meta-call mechanism offered by SWI-Prolog is to use variables as a subclause (which should of course be bound to a valid goal at runtime). A meta-call is slower than a normal call as it involves actually searching the database at runtime for the predicate, while for normal calls this search is done at compile time.

[ISO]call(:Goal)
Call Goal. This predicate is normally used for goals that are not known at compile time. For example, the Prolog toplevel essentially performs read(Goal), call(Goal). Also a meta predicates such as ignore/1 are defined using call: 
ignore(Goal) :- call(Goal), !.
ignore(_).

Note that a plain variable as a body term acts as call/1 and the above is equivalent to the code below. SWI-Prolog produces the same code for these two progams and listing/1 prints the program above. 

ignore(Goal) :- Goal, !.
ignore(_).

Note that call/1 restricts the scope of the cut (!/0). A cut inside Goal only affects choice points created by Goal.

[ISO]call(:Goal, +ExtraArg1, ...)
Append ExtraArg1, ExtraArg2, ... to the argument list of Goal and call the result. For example, call(plus(1), 2, X) will call plus(1, 2, X), binding X to 3.

The call/[2..] construct is handled by the compiler. The predicates call/[2-8] are defined as real (meta-)predicates and are available to inspection through current_predicate/1, predicate_property/2, etc.76Arities 2..8 are demanded by ISO/IEC 13211-1:1995/Cor.2:2012. Higher arities are handled by the compiler and runtime system, but the predicates are not accessible for inspection.77Future versions of the reflective predicate may fake the presence of call/9.. . Full logical behaviour, generating all these pseudo predicates, is probably undesirable and will become impossible if max_arity is removed.

[deprecated]apply(:Goal, +List)
Append the members of List to the arguments of Goal and call the resulting term. For example: apply(plus(1), [2, X]) calls plus(1, 2, X). New code should use call/[2..] if the length of List is fixed.
[deprecated]not(:Goal)
True if Goal cannot be proven. Retained for compatibility only. New code should use \+/1.
[ISO]once(:Goal)
Make a possibly nondet goal semidet, i.e., succeed at most once. Defined as: 
once(Goal) :-
    call(Goal), !.

once/1 can in many cases be replaced with ->/2. The only difference is how the cut behaves (see !/0). The following two clauses below are identical. Be careful about the interaction with ;/2. The library(apply_macros) library defines an inline expansion of once/1, mapping it to (Goal->true;fail). Using the full if-then-else constructs prevents its semantics from being changed when embedded in a ;/2 disjunction. 

1) a :- once((b, c)), d.
2) a :- b, c -> d.
ignore(:Goal)
Calls Goal as once/1, but succeeds, regardless of whether Goal succeeded or not. Defined as: 
ignore(Goal) :-
        Goal, !.
ignore(_).
call_with_depth_limit(:Goal, +Limit, -Result)
If Goal can be proven without recursion deeper than Limit levels, call_with_depth_limit/3 succeeds, binding Result to the deepest recursion level used during the proof. Otherwise, Result is unified with depth_limit_exceeded if the limit was exceeded during the proof, or the entire predicate fails if Goal fails without exceeding Limit.

The depth limit is guarded by the internal machinery. This may differ from the depth computed based on a theoretical model. For example, true/0 is translated into an inline virtual machine instruction. Also, repeat/0 is not implemented as below, but as a non-deterministic foreign predicate. 

repeat.
repeat :-
        repeat.

As a result, call_with_depth_limit/3 may still loop infinitely on programs that should theoretically finish in finite time. This problem can be cured by using Prolog equivalents to such built-in predicates.

This predicate may be used for theorem provers to realise techniques like iterative deepening. See also call_with_inference_limit/3. It was implemented after discussion with Steve Moyle smoyle@ermine.ox.ac.uk.

call_with_inference_limit(:Goal, +Limit, -Result)
Equivalent to call(Goal), but limits the number of inferences for each solution of Goal.78This predicate was realised after discussion with Ulrich Neumerkel and Markus Triska.. Execution may terminate as follows:

  • If Goal does not terminate before the inference limit is exceeded, Goal is aborted by injecting the exception inference_limit_exceeded into its execution. After termination of Goal, Result is unified with the atom inference_limit_exceeded. Otherwise,
  • If Goal fails, call_with_inference_limit/3 fails.
  • If Goal succeeds without a choice point, Result is unified with !.
  • If Goal succeeds with a choice point, Result is unified with true.
  • If Goal throws an exception, call_with_inference_limit/3 re-throws the exception.

An inference is defined as a call or redo on a predicate. Please note that some primitive built-in predicates are compiled to virtual machine instructions for which inferences are not counted. The execution of predicates defined in other languages (e.g., C, C++) count as a single inference. This includes potentially expensive built-in predicates such as sort/2.

Calls to this predicate may be nested. An inner call that sets the limit below the current is honoured. An inner call that would terminate after the current limit does not change the effective limit. See also call_with_depth_limit/3 and call_with_time_limit/2.

setup_call_cleanup(:Setup, :Goal, :Cleanup)
Calls (once(Setup), Goal). If Setup succeeds, Cleanup will be called exactly once after Goal is finished: either on failure, deterministic success, commit, or an exception. The execution of Setup is protected from asynchronous interrupts like call_with_time_limit/2 (package clib) or thread_signal/2. In most uses, Setup will perform temporary side-effects required by Goal that are finally undone by Cleanup.

Success or failure of Cleanup is ignored, and choice points it created are destroyed (as once/1). If Cleanup throws an exception, this is executed as normal while it was not triggered as the result of an exception the exception is propagated as normal. If Cleanup was triggered by an exception the rules are described in section 4.10.2

Typically, this predicate is used to cleanup permanent data storage required to execute Goal, close file descriptors, etc. The example below provides a non-deterministic search for a term in a file, closing the stream as needed. 

term_in_file(Term, File) :-
        setup_call_cleanup(open(File, read, In),
                           term_in_stream(Term, In),
                           close(In) ).

term_in_stream(Term, In) :-
        repeat,
        read(In, T),
        (   T == end_of_file
        ->  !, fail
        ;   T = Term
        ).

Note that it is impossible to implement this predicate in Prolog. The closest approximation would be to read all terms into a list, close the file and call member/2. Without setup_call_cleanup/3 there is no way to gain control if the choice point left by repeat/0 is removed by a cut or an exception.

setup_call_cleanup/3 can also be used to test determinism of a goal, providing a portable alternative to deterministic/1: 

?- setup_call_cleanup(true,(X=1;X=2), Det=yes).

X = 1 ;

X = 2,
Det = yes ;

This predicate is under consideration for inclusion into the ISO standard. For compatibility with other Prolog implementations see call_cleanup/2.

setup_call_catcher_cleanup(:Setup, :Goal, +Catcher, :Cleanup)
Similar to setup_call_cleanup(Setup, Goal, Cleanup) with additional information on the reason for calling Cleanup. Prior to calling Cleanup, Catcher unifies with the termination code (see below). If this unification fails, Cleanup is not called.
exit
Goal succeeded without leaving any choice points.
fail
Goal failed.
!
Goal succeeded with choice points and these are now discarded by the execution of a cut (or other pruning of the search tree such as if-then-else).
exception(Exception)
Goal raised the given Exception.
external_exception(Exception)
Goal succeeded with choice points and these are now discarded due to an exception. For example: 
?- setup_call_catcher_cleanup(true, (X=1;X=2),
                              Catcher, writeln(Catcher)),
   throw(ball).
external_exception(ball)
ERROR: Unhandled exception: Unknown message: ball

call_cleanup(:Goal, :Cleanup)
Same as setup_call_cleanup(true, Goal, Cleanup). This is provided for compatibility with a number of other Prolog implementations only. Do not use call_cleanup/2 if you perform side-effects prior to calling that will be undone by Cleanup. Instead, use setup_call_cleanup/3 with an appropriate first argument to perform those side-effects.
undo(:Goal)
Add Goal to the trail. Goal is executed as ignore/1 on the first opportunity after backtracking to a point before the call to Goal. This predicate is intended to make otherwise persistent changes to the database or created by foreign procedures backtrackable if it is possible to define a goal that reverts the effect of the initial call. A typical use case is to define a backtrackable assert. 
b_assertz(Term) :-
    assertz(Term, Ref),
    undo(erase(Ref)).

Without undo/1 we can achieve something similar by leaving a choicepoint using the almost portable79assertz/2 is not part of the ISO standard but supported by multiple systems. alternative below. 

b_assertz(Term) :-
    assertz(Term, Ref),
    (   true
    ;   erase(Ref),
        fail
    ).

The undo/1 based solution avoids leaving a choice point open and, more importantly, keeps undoing the assert also if the choice point from the second alternative is pruned.

Currently the following remarks apply

  • Goal is copied when it is registered.

  • “First opportunity” means after backtracking or at the first call port reached.

  • Multiple undo goals may be scheduled that are executed as a batch. If multiple goals raise an exception, the most urgent is preserved after all goals have been executed.

  • It is not allowed for Goal to call undo/1. An attempt to do so results in a permission_error exception.

  • Note that an exception that is caught higher in the call stack backtracks and therefore ensures Goal is called.

See also snapshot/1 and transaction/1.

Tags are associated to your profile if you are logged in
Tags:
LogicalCaptain said (2020-11-04T22:49:47):0 upvotes 0 0 downvotes
Picture of user LogicalCaptain.

In this context, the following, though rather old, is highly readable:

Higher-order logic programming in Prolog

Functional programmers have shown the outstanding benefits of the higher order style of programming. It is ubiquitous in modern functional programming languages. It enables greater code reuse, encourages more abstraction and alleviates the tedium of writing many similar long-winded recursive definitions. Over the years many people have also toyed with this style of programming in Prolog but to say it has not caught on would be a gross understatement. Higher order programming has been has been advocated more in newer logic programming languages such as HiLog [CKW93], Lambda Prolog [NM88][GH95], Mercury [SHCQ5] and the many combined logic and functional languages (see [Han94]). Some advocates of these languages are apparently unaware of the techniques available to Prolog programmers, despite the efforts of Richard O’Keefe and others.

One aim of this paper is to illustrate higher order programming techniques in Prolog.

We give examples to show the interaction between higher order programming and other features of Prolog such as nondeterminism, logic variables, flexible modes, meta programming, Definite Clause Grammar notation and (in some systems) coroutining. Another aim is to point out a significant difference between two ways in which higher order features are supported in logic programming languages. The superior method was suggested by David H.D. Warren over a decade ago. Since then higher order logic programming has gone off the rails. The Prolog coding style advocated by O’Keefe and the HiLog and Mercury languages use a less flexible method which does not realise the full benefits of higher order programming. The final aim is to compare the higher order style with the “skeletons and techniques” approach to program development, one of the many approaches based on program patterns, schemata and cliches."

Higher-order extensions to PROLOG: are they needed?

Abstract: PROLOG is a simple and powerful progamming language based on first-order logic. This paper examines two possible extensions to the language which would generally be considered "higher-order". The first extension introduces lambda expressions and predicate variables so that functions and relations can be treated as 'first class' data objects. We argue that this extension does not add anything to the real power of the language. The other extension concerns the introduction of set expressions to denote the set of all (provable) solutions to some goal [i.e. the predicate setof/3]. We argue that this extension does indeed fill a real gap in the language, but must be defined with care.

[...]

The translation is such that it does not involve any unbounded increase in either the size of the program or in the number of execution steps. I therefore claim that the extensions do not add anything to the strict power of PROLOG; i.e., they do not make it feasible to program anything that was not feasible before [...]. Of course "power" is often used more loosely to cover such language properties as conciseness, clarity, or implementation efficiency (measured in bytes and milliseconds). So let us consider, on such wider grounds, two possible arguments for nevertheless incorporating these extensions into PROLOG.

  1. The extensions should be provided as primitive in the language so that they can be implemented efficiently.
  2. The extended syntax is much nicer to read and to use and should be provided as standard

Most PROLOG users would argue that one of PROLOG's main strengths is that it avoids deeply nested expressions. Instead the program is broken down into smaller, more easily comprehended units. The resulting program may be slightly longer, but it is easier to read and (what is especially important) easier to modify. Now the effect of introducing lambda expressions is directly contrary to this philosophy. It results in bigger, more deeply-nested expressions. I am therefore certainly against this part of the extension. The introduction of predicate variables, however, seems to have a certain elegance.

There is more theory in:

Higher-order Aspects of Logic Programming

Abstract: Are higher-order extensions to logic programming needed? We suggest a negative answer by showing that higher-order features are already available in pure logic programming. It is demonstrated that higher-order lambda calculus-based languages can be compositionally embedded in logic programming languages preserving their semantics and abstraction facilities. Further, we show that such higher-order techniques correspond to programming techniques often practiced in logic programming.

...

In an early paper [War82], Warren raised the question whether higher-order extensions to Prolog were necessary. He suggested that they were not necessary by modelling higher-order concepts in logic programs. His proposal modelled functions and relations intensionally by their names. As is well-known in Lisp community, such an encoding does not obtain the full power of higher-order programming. In particular, lambda abstraction and "upward" function values are absent.

An entirely different approach to the issue was pursued by Miller et al. in Lambda Prolog [MN86]. The objective here seems to be not higher-order logic programming, but logic programming over higher-order terms. While this approach has many interesting applications, particularly in meta-logical frameworks, it still leaves open the question of whether higher-order programming is possible in a standard logic programming setting. A similar comment applies to other higher-order languages like HiLog [CKW89]. In this paper, we return to Warren's question and suggest another negative answer. Using new insights obtained from the connection between linear logic and logic programming [Laf87, Abr91, Abr93, Red93b], we contend that idealized logic programming is "already higher-order" in its concept, even though one might wish to add some syntactic sugar to obtain convenience. A similar answer is also suggested by Saraswat's work [Sar92] showing that concurrent logic programming is higher-order in a categorical sense. We argue that idealized logic programming is higher-order by presenting two forms of evidence:

  • We exhibit a compositional, semantics-preserving translation from higher-order lambda calculus-based languages to logic programs.
  • We show that higher-order programming techniques are already in use in logic programming (albeit in a limited form) and that these can be generalized.