Good indexing of prolog clauses means mainly that fewer misstakes of leaving a branch in the trail of the control stack in case the algorithms rely on garbage collection. Now there are also speedups potentials for large predicates to be gain as well. Lists is matched and destructed, but not all predicate versions and alternative matches is also not covered but needs to be coded explicitly inside the goal. Let’s show how guile-log’s extensions solve this.
The first example is how we matched predicates.
f(F(X|L),g(|M)) :- append(L,M,N), X=h(F|N). % f is the same as f2 below f2(A,B) :- A =.. [F,X|L], B =.. [g|M], append(L,M,N), X =.. [h,F|N].
Guile-log destructs the arguments of a predicate just as with lists and have added a prefix version of
| to enable a destruction of all arguments to a list. It is also clear code that can be understood immediately and it is terse, also a good thing is that the destruction in the head is much less general and indexing works much better. The drawback is that
| has a special meaning inside matches.
The parser in prolog have been modified to allow expressions in the finction argument as well and we can now also do
(f+g)(X,Y) in extended matching we also allow meaning to
, ; - + \+ here
A ; B in the head means
((match(A) ; match(B)),! e.g. no backtracking and
A , B is matching the same thing with both
B therefore for:
-extended. f((Op,(< ; >))(X,Y),W) :- ...
Here we will match either
(X < Y) or
(X > Y) and bind the actual operator to
Op which is useful and gainful because the indexer is designed to do the right thing with all extra operators. The ideom above is a really great tool that enables efficient analyzation of expressions.
\+ is negation that is good to have and unary
+ enables normal unification and unary
== matching. The default is always that the expression starts in
+ mode e.g.
-extended. f(-f(+X),X). ?- f(f(1),X). X = 1 ?- f(X,Y). no
In extended matching it is possible to change the operators by using
-extended(',',och,';',eller). f(och(Op,eller(;,','))(X,Y) :- ...
In the future we will allow som basic tests like
var,integer,... etc that can increase the potential of the indexer somewhat, but it is not coded yet. also inside
== matching it can look clumsy to use
+X this is needed in order for terms to be allowed to be simply copied and used in a unification construct that follows the rules of the extended matching. These kind of unifications is not yet coded and is a todo for the future. But in principle variable binding should not need a
+ and in the future I would like this to be skipt in order to streamline