This module provides support to implement some abstract interpreter-based code scanner. It tests statically an oversimplification of the possible unification of terms and call hooks over head and literals in the body of a clause to collect certain information.

author

- Edison Mera

 call_ai(:Goal)

Calls Goal during abstract interpretation and execution

 eval_ai(Goal)

Calls Goal during abstract interpretation but ignore during execution

 skip_ai(Goal)

Calls Goal during execution bug ignore during abstract interpretation

 intr_ai(Goal)

Abstract interpret Goal but ignore during execution

 abstract_interpreter(:Goal, :Abstraction, +Options, -State) is multi

Abstract interpret :Goal, call(Abstraction, Literal, Body, State1, State2) is called over each found Literal to get an abstraction of the body of such literal. For instance, if abstraction is: abstraction(Literal, Body, State, State) :- clause(Literal, Body), the abstract interpreter becomes a typical prolog interpreter, although some optimizations makes that not accurate.

Valid options are:

location(Loc)

A location of the given Goal, used to report the location in case of error

evaluable(Eval)

Eval is a term or a list of term of the form:

M:G as Repl

if the literal being interpreted match with G, and M with the implementation module of literal, then Repl is called.

M:F/A

equivalent to M:G as R, where functor(R, F, A) succeeds.

M:G :- Body

if the literal being interpreted match with G, and M with the implementation module of literal, then continue with the interpretation of Body.

on_error(OnErr)

Calls call(OnErr, at_location(Loc, Error)) if Error is raised

 abstract_interpreter(:Goal, :Abstraction, +Options) is multi

Same as abstract_interpreter(Goal, Abstraction, Options, _)

 bottom(State1, State) is det

Sets the state of the analysis to bottom, which means that the analysis is unable to determine a solution to the Goal (universe set). Note that this could be due to a lack of precision of the analysis or simply being mathematically impossible to get a solution statically.

 abstract_interpreter_body(+Goal, +M, :Abstraction, ?State1, ?State) is multi

Like abstract_interpret(M:Goal, Abstraction, Options, State), where State1 is determined using Options, but intended to be called recursivelly during the interpretation.

 get_state(State, State, State)

Used in DCG's to get the current State

 put_state(State, _, State)

Used in DCG's to set the current State

 match_head(:Goal, :Body, ?State1, ?State) is multi

Implements the next abstraction: Only test matches of literals with heads of clauses, without digging into the body.

 match_head_body(:Goal, -Body, -From) is multi

Auxiliar predicate used to implement some abstractions. Given a Goal, unifies Body with the body of the matching clauses and From with the location of the clause.

 extra_clauses(Goal, Module, :Body, -From) is multi[multifile]

Called inside match_head_body/3 to increase the precision of the interpreter, it will define 'semantic' extra clauses, allowing for instance, analysis of dynamic predicates, interfaces, etc.

 match_noloops(:Goal, :Body, ?State1, ?State) is multi

Implements the next abstraction: Only test matches of literals with heads of clauses, and digs into the body provided that there are not recursive calls, in such a case the analysis reach bottom and we stop the recursion.