Jekejeke Minlog Reference

Jekejeke Minlog ReferenceVersion 0.8.4, May 16th, 2016

XLOG Technologies GmbH

Jan Burse Language Minlog XLOG Technologies GmbH

June 20, 2016 jekejeke_lang_min_2016_05_16_e.docx Page 2 of 74

Jekejeke Prolog

Minimal Logic 0.8.4Language Reference

Author: XLOG Technologies GmbHJan BurseFreischützgasse 14 8004 Zürich Switzerland

Date: May 16th, 2016Version: 0.22

Participants: None

Warranty & LiabilityTo the extent permitted by applicable law and unless explicitly otherwise agreed upon, XLOG Technologies GmbH makes no warranties regarding the provided information. XLOG Tech-nologies GmbH assumes no liability that any problems might be solved with the information provided by XLOG Technologies GmbH.

Rights & LicenseAll industrial property rights regarding the information - copyright and patent rights in particu-lar - are the sole property of XLOG Technologies GmbH. If the company was not the origina-tor of some excerpts, XLOG Technologies GmbH has at least obtained the right to repro-duce, change and translate the information.

Reproduction is restricted to the whole unaltered document. Reproduction of the information is only allowed for non-commercial uses. Small excerpts can be used if properly cited. Cita-tions must at least include the document title, the product family, the product version, the company, the date and the page. Example:

… Defined predicates with arity>0, both static and dynamic, are indexed on the functor of their first argument [1, p.17] ...

[1] Language Reference, Jekejeke Prolog 0.8.1, XLOG Technologies GmbH, Switzerland, February 22nd, 2010

TrademarksJekejeke is a registered trademark of XLOG Technologies GmbH.



Table of Contents1 Introduction ......................................................................................................................5

2 Minlog Examples..............................................................................................................62.1 Bonner’s Examples....................................................................................................72.2 Animals Revisited ......................................................................................................92.3 Palindrome Revisited...............................................................................................112.4 Money Revisited......................................................................................................132.5 Little Solver..............................................................................................................152.6 Tracing Revisited.....................................................................................................172.7 Type Inference ........................................................................................................19

3 Minlog Conversations.....................................................................................................213.1 Forward Debugging .................................................................................................213.2 Chart Debugging .....................................................................................................233.3 Finite Debugging .....................................................................................................25

4 Minlog Syntax ................................................................................................................264.1 Minimal Logic ..........................................................................................................26

5 Minlog Extension Packages ...........................................................................................315.1 Minimal Logic Package............................................................................................325.2 Term Domain Package............................................................................................405.3 Finite Domain Package............................................................................................435.4 Miscellaneous Package...........................................................................................505.5 System Package......................................................................................................54

6 Appendix Example Listings ............................................................................................586.1 Bonner’s Examples..................................................................................................586.2 Animals Revisited ....................................................................................................616.3 Palindrome Revisited...............................................................................................626.4 Money Revisited......................................................................................................646.5 Little Solver..............................................................................................................656.6 Tracing Revisited.....................................................................................................666.7 Subject to Occurs Check .........................................................................................67

Indexes ................................................................................................................................69Public Predicates ..............................................................................................................69Package Local Predicates.................................................................................................70Non-Private Meta-Predicates ............................................................................................71Non-Private Closure-Predicates ........................................................................................72Non-Private Syntax Operators...........................................................................................72

Pictures ................................................................................................................................74

Tables ..................................................................................................................................74

References...........................................................................................................................74



Change HistoryJan Burse, June 15th, 2011, 0.1: Initial version.Jan Burse, June 5th, 2012, 0.2: Forward chaining examples, syntax and theory section completed.Jan Burse, July 14th, 2012, 0.3: Finite domain examples, syntax and theory section completed.Jan Burse, October 15th, 2012, 0.4: Some fixes and little solver example introduced.Jan Burse, November 19th, 2012, 0.5: Index section, conversation section, tracing revisited and Bonner’s examples introduced.Jan Burse, February 26th, 2013, 0.6: Stability analysis removed.Jan Burse, May 23th, 2013, 0.7: Clauses with variable sharing introduced.Jan Burse, June 6th, 2013, 0.8: Disjunction in forward chaining and last string ops introduced.Jan Burse, August 3rd, 2013, 0.9: Forward chaining advising and attribute variables introduced.Jan Burse, October 2nd, 2013, 0.10: Subject to occurs check example introduced.Jan Burse, April 18th, 2014, 0.11: Finite domain solver is not preloaded anymore.Jan Burse, June 13th, 2014, 0.12: Forward closure and chart parsing is not preloaded anymore.Jan Burse, August 19th, 2014, 0.13: Small restructuring of CLP(FD) and back and forth operators.Jan Burse, February 11th, 2015, 0.14: The CLP(FD) examples adapted to new top-level constraint display.Jan Burse, May 28th, 2015, 0.15: Title page introduced and message lists removed.Jan Burse, August 10th, 2015, 0.16: Small extension of CLP(FD) to single infinite search.Jan Burse, January 4th, 2016, 0.18: Small extension of CLP(FD) to use objects.Jan Burse, February 25th, 2016, 0.19: New continuation queue API and when/2 predicate introduced.Jan Burse, March 7th, 2016, 0.20: Better extensibility of the forward chaining and hook integration.Jan Burse, April 13th, 2016, 0.21: New miscellaneous definitions section and new indexes section.Jan Burse, May 16th, 2016, 0.22: New modules regex, rdf and sparql introduced.



1 IntroductionThis document gives a reference of the Jekejeke Minlog module.

Minlog Examples: We show some examples uses of the Jekejeke Minlog module.

Minlog Conversations: We show how to interact with the Jekejeke Minlog module.

Minlog Syntax: We show what syntax the Jekejeke Minlog module accepts.

Minlog Theory: The Jekejeke Minlog module comes with a set of new predicates.

Appendix Example Listing: The full source code of the Jekejeke Minlog module ex-amples is given.



2 Minlog ExamplesWe show some examples of the use of the Jekejeke Minlog module. Readers who might be interested in getting a quick grip Jekejeke Minlog module and who have already a basic knowledge of forward chaining might stick to this section only.

Bonner’s Examples: Two small examples from the Jekejeke Minlog tool box for hy-pothetical and counter factual reasoning.

Animals Revisited: Normal Prolog rules can be turned into forward chaining rules by simply declaring the relevant predicates forward. The given example shows a small expert system.

Palindrome Revisited: It is also possible to execute grammar rules in a forward manner. The given example allows detecting palindromes.

Money Revisited: We show how a letter puzzle can be solved with the bundled finite domain constraint solver.

Little Solver: We present a sketch on how a little custom constraint solver can be implemented via forward chaining rules.

Tracing Revisited: We show how the standard debugger can be used to trace the execution of a simple propositional forward example.

Type Inference: We show how a sound type inference algorithm can be implemented in using a subject to occurs check constraint.



2.1 Bonner’s ExamplesTwo small examples from the Jekejeke Minlog tool box for hypothetical and counter factual reasoning. Jekejeke Minlog does not contain out of the box logical operations for hypothetical and counter factual reasoning. But there is a low level tool box which can be used to define such logical operations. Although the low level tool box forms the basis for the knowledge base update in the forward chaining component, it is also available for general use in the form of a module assume.

We essentially replicate the examples from Bonner [3][4]. A student has to take mandatory German and optionally French or Italian courses before he can grade. We can express this as a set of Prolog clauses as follows:

grade(S) :- take(S, german), take(S, french).grade(S) :- take(S, german), take(S, italian).

A useful logical operation for hypothetical reasoning is the embedded implication. It will insert a fact for the duration of a sub-goal. We can define a form of embedded implication by means from our tool box as follows:

(A -: B) :-consultable_ref(A, R),sys_assume_ref(R),call(B),sys_retire_ref(R).

With this embedded implication we can already do some forms of hypothetical reasoning. Assume that Hans has already taken French. We can then ask whether Hans would grade when he takes German or Italian. The result can be seen in the following:

take(hans, french).

?- take(hans, italian) -: grade(hans).No

?- take(hans, german) -: grade(hans).Yes ;No

Counter factual reasoning will remove a fact for the duration of a sub-goal. Let’s call this logi-cal operation embedded contraction. Again we can define a form of embedded contraction by means of our tool box as follows:

(A \: B) :-sys_clause_ref(A, true, R),sys_retire_ref(R),call(B),sys_assume_ref(R).

With this embedded contraction we can already do some forms of counter factual reasoning.Assume this time that Hans is a very eager student and that he has already taken all the courses. We can ask whether Hans would grade when he would not take Italian or German. The result can be seen in the following:



take2(hans, german).take2(hans, french).take2(hans, italian).

?- take2(hans, italian) \: grade2(hans).Yes ;No

?- take2(hans, german) \: grade2(hans).No

It is possible to use the toolbox efficiently for more elaborate applications such as adversarial planning [5]. Also note that in practical applications often the continuation variant [6] of hypo-thetical and counter factual reasoning is used. We might publish corresponding examples elsewhere.



2.2 Animals RevisitedNormal Prolog rules can be turned into forward chaining rules. To be able to use the forward chaining component in a Prolog text one has first to load the module delta. Loading the delta library will install a term expansion that will convert forward chaining clause into ordinary Prolog delta computation rules. The forward chaining clauses can appear in normal Prolog texts and are recognized by the operator (<=)/2.

The given example shows a small expert system. The example is an adaptation of the ex-ample found in the language reference for the Prolog runtime library. The Prolog text does not start anymore with the facts. Instead we will keep the facts dynamically. But we don’t want that the facts interfere with other threads. We therefore declare the facts as thread_local/1. Further new facts will be calculated by delta computation rules, we therefore declare the corresponding delta predicates as forward/1.

:- thread_local motion/1, Etc...:- forward motion/2, Ect..Etc..

The revised Prolog text will then continue with the rules. To mark a rule as a forward chaining rule the implication sign (:-)/2 has to be replaced by the forward chaining implication sign (<=)/2. Further we need to annotate the literals in the body of the forward chaining clauses and decided for the head of the forward chaining clauses whether we desire further forward chaining. In both cases we use (+)/1:

+class(mamal) <= +motion(walk), +skin(fur).Etc..

+animal(rodent) <= +class(mamal), +diet(plant).Etc..

The Prolog text is found in the support .zip under the file name ‘animals.p’. The Prolog text needs only to be read-in a single time. We will be able to add the facts and compute the clo-sure inside a query via the hypothetical reasoning and the forward chaining. To make the hypothetical reasoning also available in the top-level, besides the Prolog text of the example, we first need to load the module hypo:

?- use_module(library(minimal/hypo)).

We will use the embedded implication variant (<=)/1 in connection with the (+)/1 to formulate our query. The (<=)/1 predicate will try to assume a construct for the duration of the continua-tion and the (+)/1 annotation will compute the forward closure. Here is an example run:

?- <= +motion(walk), <= +skin(fur), <= +diet(meat), animal(X).X = cat



The result of the forward closure will only be temporarily added so that there is no accumula-tion from query to query. We can probe that the no facts have been kept by a top-level query. Here is an example run:

?- animal(X).No

When no delete sets are present, the forward closure computation yields the same set of facts independent of the order the facts arrive. We can probe that that a permutation of the first query yields the same result by a top-level query. Here is an example run:

?- <= +diet(meat), <= +skin(fur), <= +motion(walk), animal(X).X = cat



2.3 Palindrome RevisitedIt is also possible to execute grammar rules in a forward manner by a chart parser. To be able to use the chart parser in a Prolog text one has first to load the chart library. Loading the chart library will install a term expansion that will convert chart rules first into forward chaining rules and then into ordinary Prolog delta rules. Loading the chart library requires the Jeke-jeke Minlog capability and is done as follows:

:- use_module(library(minimal/chart)).

The example is an adaption of the example already found in the language reference of the Jekejeke Prolog runtime library. It allows detecting palindromes. The way forward grammar rules are currently conceived it is not anymore possible to use them to generate text. It is only possible to detect text. In ordinary DCG rules text is passed around in the logical varia-bles of the non-terminals. In chart DCG rules the text will be represented as facts for the predicate ‘D’/2. For the text “bert” the following facts will be temporarily added:

'D'(97, 3).'D'(110, 2).'D'(110, 1).'D'(97, 0).

The facts will be supplied to the forward chaining component in the above order, from the last text element to the first text element, right-to-left. This is a little bit unusual but has certain advantages. First since the order is fixed it is possible to check for arrived facts only in the first literal of a forward grammar rule. This reduces the number of generated delta rules and speeds up the execution of the parser. Second it is possible to use auxiliary conditions as known from normal definite clause grammars since the goals will be executed left-to-right as soon as the left-most fact arrives.

But we have to see to it that the non-terminals generate ground attributes, since non-ground attributes would currently not yet be correctly preserved by the forward chaining component. This bottom-up condition is not a problem for the palindrome example. The Prolog text needsalso to import the clause reference module since delta computation rules make use of clause references. Further we need a static/1 declaration for those non-terminals that do not occuras some first non-terminal of a DCG chart rule. The DCG chart rules itself are denoted by the operator (==>)/2:

:- use_module(library(experiment/ref)).

:- static palin/5.

palin([], [Middle]) ==>[Middle].

palin([Middle], []) ==>[Middle, Middle].

palin([Border | List], Middle) ==>[Border], palin(List, Middle), [Border].



The embedded implication (=>)/2 or alternatively the continuation form (<=)/1 from the mod-ule hypo can be used to start the chart parser. When used with the chart/3 construct the commands will add the ‘D’/2 facts. The (+)/1 annotation automatically set inside the chart/3 construct so that the commands will also compute the closure. The commands will do so in atemporary manner. Before we can use the commands from the top-level, besides the Prolog text of the example, we need to load the module hypo as well:


?- <= chart("bert", _), listing('D'/2).:- thread_local 'D'/2.'D'(116, 3).'D'(114, 2).'D'(101, 1).'D'(98, 0).

The chart/3 construct can also be used to query a non-terminal when used in a goal position and not in a term aka clause position. The goal expansion will already expand such a con-struct at compile time, so that as long as the first argument of chart/3 is not a variable the end-user doesn’t has to worry about performance. We can detect the same text as with the normal definite clause grammars. Both the positive and the negative example do their job also in forward chaining:

?- <= chart("racecar", N), chart(palin(X1,Y1), N).X1 = [114,97,99],Y1 = [101]

?- <= chart("bert", N), chart(palin(X1,Y1), N).No

Forward grammar rules will loop when there are productions with a single goal in the body that form a cycle. On the other hand if this cycle condition is not met forward grammar rules can easily deal with left recursion and they can also easily identify parse chunks.



2.4 Money RevisitedWe show how a letter puzzle can be solved with the bundled finite domain constraint solver.The letter puzzle is already found in the language reference of the Jekejeke Prolog runtime library. There the puzzle was solved via the method of generate and test. This method uses goals G1, .., Gn to enumerate exemplars of a collection and goals T1,..,Tm to verify a condi-tion. The problem is then solved via backtracking over the following query:

G1, .., Gn, T1, .., Tm

For constraint solving the problem is posed the same way. But the constraint solver will not perform any backtracking during the setup phase. Only in the solving phase the constraint solver will then intelligently pick and rearrange the goals. The heuristic search component is responsible for picking the first generator Gi. The forward checking component will then cross out relevant tests Tj, .., Tk:

Gi, Tj, .., Tk

If a test fails backtracking is issued until the recent generator is exhausted. The process might then even backtrack to previous generators but later pick again totally different genera-tors. If all tests succeed a further generator and tests are picked. The search succeeds when all generators and relevant tests have been processed.

Let’s turn to the letter puzzle. To be able to use the finite domain constraint solver parser in a Prolog text one has first to load the clpfd library. Loading the clpfd library will define the pred-icates and syntax operators of the finite domain constraint solver. Loading the clpfd library requires the Jekejeke Minlog capability and is done as follows:

:- use_module(library(finite/clpfd)).

Since our finite domain constraint solver allows the use native Prolog variables we can use these to represent individual letters. The part that generates the permutations will therefore read as follows. The predicate ins/2 states that the letters will have values in the range of 0..9. The next predicate all_different/1 then states that the letters should be distinct:

puzzle(X) :-X = [S,E,N,D,M,O,R,Y],X ins 0..9,all_different(X),

The code then continues by phrasing the condition that needs to be verified. These condi-tions read as in the original example except that the Prolog relations (=:=)/2 and (=/=)/2 are replaced by the relations (#=)/2 and (#\=)/2 of the finite domain constraint solver.

M #\= 0,S #\= 0,

1000*S + 100*E + 10*N + D +1000*M + 100*O + 10*R + E #=

10000*M + 1000*O + 100*N + 10*E + Y,



The predicate label/1 will then start the constraint There is no need to retrieve the variable values via the predicate indomains/2 since labelling will only succeed with all the given varia-bles instantiated to a constant.

label(X).

The source code of the puzzle/1 predicate is found in the appendix. It can be ensure loaded from the top-level. To then call the puzzle/1 predicate from the top-level we do not need to load the clpfd library again, since querying the puzzle/1 doesn’t require any predicates or syntax operators from the finite domain constraint solver:

?- puzzle(Z).Z = [9,5,6,7,1,0,8,2] ;No

For certain problems the constraint solver can considerably reduce the search space and thus perform much quicker than the standard backtracking solution. For the letter puzzle the standard Jekejeke Prolog backtracking solution takes around 3000ms, whereas the Jekejeke Minlog constraint solving solution only needs around 30ms in the average.



2.5 Little SolverWe present a sketch on how a little custom constraint solver can be implemented via forward chaining rules. The basic idea of the sketch can be used as a boiler plate to implement vari-ous constraint solvers. But more able and efficient solvers probably need additional ideas.Our little solver will allow elementary reasoning for the following constraints:

X = c, c is a numberX D, D is a finite set of numbers

Our little solver will use atoms to represent constraint variables. Many existing Prolog sys-tems use Prolog variables to represent constraint variables. We might also do so in the fu-ture, but atoms are currently easier to deal with in forward chaining rules. We will represent the constraints by forward facts. The forward chaining rules will implement the desired ele-mentary reasoning.

We start with the rules for the X = c constraints. The constraint will be represented by bound/2 forward facts. We find only two rules:

X = c, X = c X = cX = c, X = d , c d

To implement these rules we will need to draw upon all features of our forward chaining en-gine. In particular we will make use of the annotations (-)/1, (+)/1 and (=)/1. And we will also make use of the unit/0 and zero/0 assumption constructs. In the first rule we need an arrival and delete (=)/1 annotation since two equalities are replaced by a single equality. In the sec-ond rule we need a zero since the result is bottom. We also make use of the cut (!):

:- use_module(library(mininal/delta)).

% bound(+Atom, +Elem):- thread_local bound/2.

unit <= =bound(X, C), bound(X, C), !.zero <= +bound(X, _), bound(X, _).

Let’s turn to the rules for the X D constraints. The constraint will be represented by do-main/2 forward facts. We find rules that transform a domain/2, that combine a domain/2 with a bound/2 and that combine a domain/2 with another domain/2:

X {} X {c} X = cX D, X = c X = c, c DX D, X = c , c DX D, X E X D E



The above rules need additional computations. The rules that combine a domain/2 and a bound/2 will make use of a member/2 predicate to check the member ship (). The rules that combine a domain/2 with another domain/2 will make use of an intersection/2 predicate to compute the set intersection (). The implementation of these predicates is drawn from some standard modules. The forward rules read as follows:

% domain(+Atom, +List):- thread_local domain/2.

zero <= +domain(_, []), !.+bound(X, C) <= =domain(X, [C]), !.unit <= =domain(X, D), +bound(X, C), member(C, D), !.zero <= +domain(X, _), +bound(X, _).+domain(X, F) <= =domain(X, D), -domain(X, E), intersection(D, E, F).

The forward store and thus constraint store can be inspected with the predicate listing/1. The forward chaining can be triggered via the predicate (<=)/1. Let’s run some tests:


?- <= +domain(x,[1]), listing(bound/2), listing(domain/2).bound(x, 1).

?- <= +domain(x,[1,2,3]), <= +domain(y,[2,3,4]), listing(bound/2), listing(domain/2).

domain(x, [1,2,3]).domain(y, [2,3,4]).

?- <= +domain(x,[1,2,3]), <= +domain(x,[2,3,4]), listing(bound/2), listing(domain/2).

domain(x, [2,3]).

?- <= +domain(x,[1,2,3]), <= +bound(x,4), listing(bound/2), listing(domain/2).

No



2.6 Tracing RevisitedWe show how the standard debugger can be used to trace the execution of a simple forward propositional example. The example consists of the following forward declarations and corre-sponding forward clauses. The dependency of the involved predicates is shown in the dia-gram besides the forward clauses:

:- thread_local p/0, r/0, q/0, s/0.:- forward p/1, r/1, q/1, s/1.

+r <= +p.+q <= +p.+s <= +q, +r.

The query that interests us will post a fact for p and thus trigger a couple of reactions of the forward chaining component so that in the end we can verify that the fact s holds. We expect that the forward execution resembles a bottom-up traversal of the dependency graph. With-out tracing the query can be immediately executed as follows:

?- use_module(library(hypo)).Yes

?- <= +p, s.Yes

We can switch on the trace mode via the trace/0 command and start tracing our query. The standard debugger with the forward port cosmetics shows new events by post ports. In paral-lel we mark and number corresponding nodes in the dependency graph. What we first will see is how the new fact p first triggers some new facts r and q:

?- trace.Yes

?- <= +p, s.0 Post p ?0 Diff + r ?0 More + r ?0 Diff + q ?0 More + q ?0 Done p ?

Since new deltas have been computed the forward chaining component will pick the first del-ta r and treat it as a new fact r. When computing the delta for r we will see that the rule for s is tried, since we will see a call to q. But since q has not yet been considered a new fact no delta will be computed:

0 Post r ?1 Call q ?1 Fail q ?0 Done r ?

s

q r

p

s

q r

p1

s

q r

p1

2



As a next step the forward chaining component will pick the second delta q and treat it as a new fact q. Now when computing the delta for q we will see again that the rule for s is tried, but this time there is a call to r. Fortunately since previously r has already been considered a new fact a delta will be computed:

0 Post q ?1 Call r ?1 Exit r ?0 Diff + s ?0 More + s ?

Since there are choice points left, we are not yet finished. We take the opportunity to also show how the ancestor inspection works for new facts. So we will issue the g command at some point and see that there is a fact in the call chain:

1 Redo r ?g0 Fact q1 Redo r ?1 Fail r ?0 Done q ?

This time we are again not yet finished since the forward chaining component is exhaustive and unfocused. Although the second part of the initial query can already be satisfied the for-ward chaining component will treat the delta s as a new fact s.

0 Post s ?0 Done s ?0 Call s ?0 Exit s ?

Yes

By entering a semicolon (;) we could continue tracing the example. But since the forward chaining component has already exhaustively computed all new facts not much will happen, except for a redo and fail of checking the fact s and posting the fact p. The example should have given a small illustration of the bottom-up nature of forward execution.

s

q r

p1

23

s

q r

p1

23

4



2.7 Type InferenceWe show how a sound type inference algorithm can be implemented in using a subject to occurs check constraint. The occurs-check is a check that is needed for a sound unification. It verifies that a variable is not bound to a term which contains the variable itself. Since this check is costly it is often omitted from Prolog systems. As result a Prolog system which omitsthe occurs-check might produce wrong results.

Consider the following problem of inferring a simple type for a lambda expression. Assume lambda expressions are built from applications app/2, abstractions lam/1 and variables. Sim-ple types are either variables or functions spaces ->/2. Consider contexts T1 : X1, .., Tn : Xnthat enumerate the variables of a lambda expression and their types. Let Γ |- T : E denote that the lambda expression E provides context Γ and has the simple type T. We can readily write down the following inference rules:

----------------- (Id)A : X |- A : X

Γ |- A -> B : S Δ |- A : T Γ, A : X |- B : T---------------------------------- (MP) --------------------------- (->R)

Γ, Δ |- B : app(S,T) Γ |- A -> B : lam(X,T)

It is straight forward to produce a predicate typed/3 that takes a context Γ, a lambda expres-sion E and then derives the type T if a smaller context Δ subset Γ exists such that Δ |- T : E. Unfortunately without a sound unification, we might assign types to lambda expressions we do not want them to have a simple type. For example we might get an erroneous affirmativefor the self-application app(F,F):

/* SWI-Prolog */?- typed(app(F,F), [F-A], B).A = (A->B).

Or it might even happen that the Prolog system crashes:

/* Jekejeke Prolog */?- typed(app(F,F), [F-A], B).java.lang.StackOverflowError

There are a number of options to avoid either behaviour. Some Prolog systems provide a global flag that switches on the occurs-check for all unifications. Other Prolog systems im-plement the ISO predicate unify_with_occurs_check/2. Both approaches have their disad-vantage. The former might slowdown unifications that don’t need the occurs-check, and the latter might need some cumbersome code rewriting. We present an alternative here by means of the Jekejeke Minlog attribute variables.

The idea is to use the sto/1 constraint that allows imposing an occurs check on the supplied variables. The sto/1 constraint is provided as part of the module herbrand. The detailed source code of this module can be found in the open source code corner of the Jekejeke Minlog web site. The sto/1 constraint is implemented with the help of attribute variables and eagerly checks the condition before the attribute variable is even instantiated. Here are some example uses of the sto/1 constraint:



?- use_module(library(term/herbrand)).

?- sto(X), X=f(Y).X = f(Y),sto(Y)

?- sto(X), X=f(Y), Y=g(X).No

The sto/1 constraint is now deployed like a variable declaration. Whenever one finds a fresh variable that needs an occurs check the sto/1 constraint should be used. In the case of our typed/3 predicate we only find the (MP) rule that needs an additional sto/1 constraint. The (MP) rule is non-analytic it introduces a new formula A in backward chaining. We therefore define a revised typed2/3 predicate with the following modified clause:

typed2(app(E,F), C, T) :-sto(S), typed2(E, C, (S->T)), typed2(F, C, S).

The sto/1 constraint needs also to be deployed for Prolog queries in the top-level. The gen-eral rule is the same here as for clauses. Whenever one finds a fresh variable that needs an occurs check the sto/1 constraint should be used. It is important that the sto/1 constraint is used before the argument receives a cyclic term. Since Jekejeke Prolog doesn’t support cy-clic terms, the sto/1 constraint will hang if it receives an already cyclic term.

Here are some examples for an accordingly modified predicate typed2/3:

?- sto((A,B,C)), typed2(app(E,F), [E-A,F-B], C).A = (B->C),sto(C),sto(B)

?- sto((A,B)), typed2(app(F,F), [F-A], B).No

?- sto(A), typed2(lam(X,lam(Y,app(Y,X))), [], A).A = (_A->(_A->_B)->_B),sto(_B),sto(_A)

The predicate sto/1 might be a viable alternative to the other two approaches of introducing an occurs check into a Prolog text. The sto/1 predicate has the advantage that it can be selectively applied to variables where necessary. On the other hand it should be noted that the sto/1 predicate introduces an additional memory footprint in the form of allocated attribute variables and hooks.



3 Minlog ConversationsWhen used in connection with the Jekejeke Prolog development environment, the Jekejeke Minlog module will enhance the default debugger user interaction.

Forward Debugging: Ports related to event handling will be displayed differently dur-ing query debugging and ancestor inspection.

Chart Debugging: Forward debugging for chart parsing will show the behaviour of the transformed forward clauses.

Finite Debugging: t.b.d.

3.1 Forward DebuggingPorts related to event handling will be displayed differently during query debugging and an-cestor inspection. The delta computation of a fact F/A is carried out by a predicate F/A+1. The port name and the goal of a delta computing predicate are adapted as follows. During query debugging the ‘call’ and ‘fail’ port have been replaced by a ‘post’ and ‘done’ port that will show the newly arrived fact.

Delta Computation

Post <Fact>

Done <Fact>

Diff <Delta>

More <Delta>

Figure 1: Forward Debugging Ports

Further the ‘exit’ and ‘redo’ port have been replaced by a ‘diff’ and ‘more’ port that will show the delta. The deltas consist of the insert sets only. Delete sets will be marked by the (-)/1 and shown during the initial trace of the forward clause. Finally during ancestor inspection the ‘goal’ pseudo port has been replaced by a ‘fact’ pseudo port that will show the newly ar-rived fact.

Forward rules that contain delete sets are internally translated into delta computation clauses that work with delayed deletes and/or clause references. The port cosmetics will hide the details of these translations and show the insert set together with the delete set. Here are some forward clauses with a delete set from the little solver example:

+bound(X, C) <= =domain(X, [C]), !.[...]+domain(X, F) <= =domain(X, D), -domain(X, E), intersection(D, E, F).



These forward clauses will be translated as follows:

domain(X, [C], A) :- !,sys_unify_notrace(A, sys_drop(+bound(X,C),unit)).

domain(X, D, B) :-sys_capture(sys_clause_expose(domain(X,E), true, A)),intersection(D, E, F),sys_unify_notrace(B, sys_drop(+domain(X,F),A)).

Since in both forward clauses the incoming fact is deleted the translations make use of de-layed deletes via the sys_drop/2 result. The forward fact that caused the sys_drop/2 will not be shown during a call, instead it will be shown as a delete element inside the delta separat-ed by the forward clause operator (<=)/2.

When we trace the first forward clause we do see the delete element in the delta:

?- <= +domain(x,[1]).0 Post domain(x, [1]) ?0 Diff + bound(x, 1) <= - domain(x, [1]) ?

Etc..

When we trace the second forward clause we do see the first delete element in a call and the second delete element in the delta:

?- <= +domain(x,[1,2,3]), <= +domain(x,[2,3,4]).[...]

1 Call - domain(x, _B) ?1 Exit - domain(x, [1,2,3]) ?1 Call intersection([1,2,3], [2,3,4], _D) ?s

> 1 Exit intersection([1,2,3], [2,3,4], [2,3]) ?0 Diff + domain(x, [2,3]) <= - domain(x, [2,3,4]) ?

Etc..

Last but not least the forward debugging inherits all properties of the default debugger. For example it will not yet eliminate unnecessary choice points for deterministic executions. The forward debugging also inherits all commands of the default debugger. This includes spy points commands, goal skipping commands and the various inspection commands.



3.2 Chart DebuggingThe tour doesn’t work for release 1.0.3 since the forward chaining rule format has changed. Please be patient for a subsequent release when we have fixed the tour.

Forward debugging for chart parsing will show the behaviour of the transformed forward clauses. Chart parsing can be invoked via the predicate postchart/2. This predicate will see to it that the following phases are executed:

Building the bottom of the chart. Building the forward closure of the chart. Querying the chart.

To build the bottom of the chart the postchar/2 predicate will initially post ‘D’/3 facts for the input tokens. It has been arranged via some call-site transfer that the initially posted ‘D’/3 facts can already be seen in the debugger. Here are some steps of the revisited palindrome example:

Example:?- trace.Yes?- postchart(palin(X, Y), "anna").

0 Call postchart(palin(X,Y), [97,110,110,97]) ?1 Post 'D'(97, 3, 4) ?

[...]

The following phase of building the forward closure of the chart is interleaved with the initial phase of building the bottom of the chart. Debugging the forward closure is accommodated by the port cosmetics of the forward debugging for the transformed forward clauses. Here are some steps of the revisited palindrome example:

Example:?- postchart(palin(X, Y), "anna").[...]

1 Diff palin([], [97], 3, 4) ?1 More palin([], [97], 3, 4) ?2 Call 'D'(97, 4, _B) ?

[...]

Since the forward closure computation is exhaustive and by the way the postchart/2 predi-cate has been realized the chart querying phase is only entered when the two preceding phases have been completed. It has also been arranged via some call-site transfer that the query is seen in the debugger. Here are some steps of the revisited palindrome example:

Example:?- postchart(palin(X, Y), "anna").[...]

1 Call palin(X, Y, 0, 4) ?1 Exit palin([97,110], [], 0, 4) ?0 Exit postchart(palin([97,110],[]), [97,110,110,97]) ?

X = [97,110],Y = []



The chart debugging also inherits all commands of the forward debugging. Like in normal DCG debugging when setting spy points, chart elements have to be addressed by F/N+2 for a non-terminal F/N. The delta computation predicates can be addressed by F/N+3.



3.3 Finite Debuggingt.b.d.



4 Minlog SyntaxThe Jekejeke Minlog module extends the syntax of Prolog texts by forward clauses and chart rules. We show what additional syntax the Jekejeke Minlog module accepts.

Minimal Logic: The Jekejeke Minlog modules enhance the syntax ordinary Prolog texts and ordinary Prolog sessions.

Miscellaneous Definitions: The interpreter keeps track of flags and properties.

4.1 Minimal LogicThe Jekejeke Minlog modules enhance the syntax ordinary Prolog texts and ordinary Prolog sessions.

Hypothetical Goals: Prolog texts and Prolog sessions may now make use of hypo-thetical reasoning recognized by the (=>)/2 and the (<=)/1 operators.

Forward Clauses: Theory texts can now contain forward chaining rules recognized by the (<=)/2 operator.

Chart Rules: Grammar rules can now act in a forward chaining manner driven by special non-terminal events.



Hypothetical GoalsProlog texts and Prolog sessions may now make use of hypothetical reasoning recognized by the (=>)/2 and the (<=)/1 operators. These operators first assume a term before either executing a goal or the continuation. The assumed terms are basically captured by the clauses syntax. The goal syntax extends the existing goal syntax but the clauses syntax is a separate syntax on its own.

goal’ --> hp_goal | callable | variable.hp_goal --> hp_clauses => goal

| <= hp_clauses.

hp_clauses --> hp_clause [ "/\" hp_clauses ] | "unit"| "zero"

hp_clause --> term "#" hp_clause | head ":-" body| head.

Examples:?- p(a) /\ p(b) => listing(p/1). % a hypothetical query?- X#p(X) => p(Y). % a hypothetical query

The goal syntax is extended by the embedded implication (=>)/2 and by the continuation var-iant (<=)/1. The clauses syntax is based on the existing clauses syntax but we can assume more than only ordinary Prolog facts and rules. There are some additional constructs such as the falsum zero/0 and the universal quantifier (#)/2. User defined constructs are possible ei-ther via the forward chaining clauses or by extending the multi-file operator hooks.



Forward ClausesTheory texts can now contain forward chaining clauses recognized by the (<=)/2 operator. A forward chaining clauses consists of a head and a body. The body defines the condition when something is assumed and the head defines what is assumed. The body establishes the relevant arrived facts and the delete set. The assumption also indicates when the forward chaining engine should be called again.

clause’ --> fw_clause| head ":-" body| head.

fw_clause --> hp_clauses "<=" fw_body.

fw_body --> fw_goal [ "," fw_body ].fw_goal --> "-" callable

| "+" callable | "=" callable | goal.

hp_clause’ --> "+" callable| term "#" hp_clause | head ":-" body| head.

Examples::- forward p/2, q/2, r/2. % a delta predicate declaration.unit <= =q(X), q(X). % a forward chaining clause.+q(X) <= =r(X). % a forward chaining clause.

The syntax for the body is a non-empty conjunction of annotated literals and goals. The syn-tax is an extension of the normal body syntax but it consists of a separate syntax on its own. The annotation allows defining whether a literal is a relevant arrived fact (+)/1 or whether a literal should be included in the delete set (-)/1 or both (=)/1. The body of a forward chaining rule needs to have at least one relevant arrived fact.

Those parts of the body that are not annotated literals can be arbitrary goals that are solved via the normal backward chaining of the Prolog interpreter. The syntax for the head slightly extends the syntax for hypothetical assumptions from the previous section. All hypothetical assumption constructs can be used, included user defined extensions. The forward chaining engine defines its own extension if the form of the operator (+) which indicates that a new fact arrives instead of simply assuming a given clause.



Chart RulesTo allow forward chaining grammar rules we provide a variant of DCG rules. The ordinary DCG rule make use of [T|O] = I for terminals. The chart DCG rules introduced here make use of ‘D’(T,I,O) for terminals. Chart DCG rules are recognized by the new operator (--:)/2 respec-tively (==>)/2. Push backs are currently not supported by chart DCG rules.

gr_rule’ --> ch_head "--:" ch_body |ch_head "==>" ch_body |gr_head "-->" gr_body.

ch_head --> [ "+" ] non-terminal.ch_body --> ch_goal [ "," ch_body ].ch_goal --> set | list

| [ "+" ] non-terminal| "!" | "fail" | "\+" ch_goal.

Examples:+p ==> +q. % a forward grammar rule.

Compared to ordinary DCG rules we do not support the condition (->)/2 and the meta-calls call/n in the body of chart DCG rules. On the other hand the forward chaining prefix plus (+) is supported for goals and for the head. The (--:)/2 operator is used for backward chaining chart rules and the (==>)/2 operator is used for forward chaining chart rules. The delete op-erator minus (-) in forward chaining chart bodies is currently not recognized. There are cur-rently no assumption constructs that would be recognized in the chart head.



4.2 Miscellaneous DefinitionsThe interpreter also needs to keep track of flags and properties definitions. The following flags and properties are provided by the Jekejeke Prolog Minimal Logic extension:

Prolog Flags: The predefined Prolog flags.

Predicate Properties: The predefined predicate properties.

Source Properties: The predefined source properties.

Atom Properties: The predefined atom properties.

Prolog FlagsProlog flags can be accessed via the system predicates current_prolog_flag/2 and set_prolog_flag/2. The following Prolog flags are supported by the Jekejeke Prolog Minimal Logic extension:

Predicate PropertiesPredicate properties can be accessed via the system predicates predicate_property/2, set_predicate_property/2 and reset_predicate_property/2. The following predicate properties are supported by the Jekejeke Prolog Minimal Logic extension:

cosmetic: See the module delta section.

Source PropertiesSource properties can be accessed via the system predicates source_property/2, set_source_property/2 and reset_source_property/2. The following source properties are supported by the Jekejeke Prolog Minimal Logic extension:

Atom PropertiesAtom properties can be accessed via the system predicates atom_property/2 and updated copies of atoms can be obtained via the predicates set_atom_property/3 and reset_atom_property/3. The following atom properties are supported by the Jekejeke Prolog Minimal Logic extension:



5 Minlog Extension PackagesThe Jekejeke Minlog module comes with a set of new predicates. Predicates can be grouped into theories and we present them as such:

Minimal Logic Package: This theory groups the predicates that extend the expres-siveness of normal Prolog.

Term Domain Package: This theory groups the predicates for constraint solvers over term domains.

Finite Domain Package: This theory groups the predicates of the finite domain con-straint solver.

Miscellaneous Package: This theory is concerned with miscellaneous predicates.

System Package: This theory is concerned with accessing the Prolog system.



5.1 Minimal Logic PackageThis theory groups the predicates that extend the expressiveness of ordinary Prolog. We find the following topics:

Module assume: This Jekejeke Minlog module provides an assumption toolbox for clause references and variable hooks.

Module hypo: This Jekejeke Minlog module provides a couple of connectives for hy-pothetical reasoning.

Module delta: This Jekejeke Minlog module provides a couple of directives and pred-icates to control the forward chaining component.

Module chart: This Jekejeke Minlog module also allows executing definite clause grammars (DCGs) in a forward manner.



Module assumeClauses and attribute variable hooks are identified by their reference data type. The predi-cate sys_assume_ref/1 will assume the given clause or hook for the duration of the continua-tion, whereas the predicate sys_retire_ref/1 will retire the given clause or hook for the dura-tion of the continuation.

Example:hook(V, T) :-

write('bind '), write(V), write(' to '), write(T), nl.

?- sys_ensure_hook(X, hook), X = 99.bind _A to 99X = 99.

The predicate sys_ensure_hook/2 takes care of the compilation of a hook into a hook refer-ence in case the hook is not yet associated with an attribute variable for the duration of the continuation. The variant sys_ensure_hook/3 does the same job during the execution of the given goal.

The predicate sys_assume_cont/1 temporarily pushes the given goal on the continuation queue. For more information on the continuation queue see the module cont.

The following assumption toolbox predicates are provided:

sys_assume_ref(R):The predicate temporarily inserts the clause or hook referenced by R at the bottom for the duration of the continuation.

sys_retire_ref(R):The predicate temporarily removes the clause or hook referenced by R for the dura-tion of the continuation.

sys_ensure_hook(A, H, G):The predicate temporarily ensures that the hook H is in the hook list of the attribute variable A for the duration of the goal G and succeeds whenever G succeeds.

sys_ensure_hook(A, H):The predicate temporarily ensures that the hook H is in the hook list of the attributevariable A for the duration of the continuation.

sys_assume_cont(G):The predicate temporarily pushes the goal G on the continuation queue.



Module hypoThis Jekejeke Minlog module provides a couple of connectives for hypothetical reasoning. Hypothetical reasoning provides a new logical operator (=>)/2 for embedded implication. This logical operator takes a construct of the left side which is assumed and goal on the right side which is executed. The predicate (<=)/1 is a variant of the predicate (=>)/2 where the contin-uation is invoked after assuming the construct. The general forms are:

C => G % Embedded Implication.<= C % Continuation Variant.

The way the interpreter proceeds when assuming the construct C depends on the used con-structs. We currently support the conjunction (/\)/2, the universal quantification (#)/2, the re-tract (-)/1, the verum unit/0 and the falsum zero/0. If none of these constructs is encountered the construct can be either a fact or a rule. Variables that are not universally quantified will then be treated as inter-clausal.

Example:?- p(X) => p(Y).Y = X?- X#p(X) => p(Y).Yes

The predicates (=>)/2 and (<=)/1 can be extended by the end-user by adding new clauses to these predicates. The end-user needs to extend the predicate hypo_abnormal/1 as well, by patterns for the newly supported constructs. The construct (-)/1 can be extended by the end-user by adding new clauses to the predicates (=>)/2 and (<=)/1. The end-user needs to ex-tend the predicate minus_abnormal/1 as well, by patterns for the newly supported retract.

The following hypothetical reasoning predicates are provided:

C => G:The predicate temporarily assumes the construct C while solving the goal G. The predicate succeeds whenever the construct C and then the goal G succeed. The predicate is multi-file and can be extended by the end-user.

<= C:The predicate temporarily assumes the construct C while solving the continuation. The predicate succeeds whenever the construct C succeeds. The predicate is multi-file and can be extended by the end-user.

hypo_abnormal(A):The predicate succeeds for those constructs A that are extended in (=>)/2 or (<=)/1. The predicate is multi-file and can be extended by the end-user.

minus_abnormal(A):The predicate succeeds for those retracts A that are extended in the (-)/1 construct. The predicate is multi-file and can be extended by the end-user.



The following hypothetical reasoning constructs are provided. The (hypo) marking indicates that these operators are only understood in the context of the left hand side of the hypothet-ical reasoning operator (=>)/2 or in the right hand side of the (<=)/1 variant:

X # P (hypo):The construct designates X as local when assuming P.

- P (hypo):The construct retires P.

P /\ Q (hypo):The construct assumes P and then Q before solving.

unit (hypo):The construct does nothing before further solving.

zero (hypo):The construct prevents further solving.



Module deltaThis Jekejeke Minlog module provides a couple of operators and predicates to define forward chaining clauses. A forward chaining clause is recognized by the (<=)/2 operator. A forward chaining clause will be rewritten into multiple delta computation rules. A delta computationrule is able to react to the arrival of a single fact. The left hand side accepts all constructors already known from hypothetical reasoning:

C <= B % Forward Clause.

The delta computation has functor F/N+1 for an arriving fact with a functor F/N. The forward clause body is a conjunction of literals. Each literal in the body has to be annotated either fordelete set inclusion, for delta computation or for both. If a literal is not annotated it is checked in backward chaining fashion. The following annotations are provided:

-P % The literal P is a fact from the database that is removed.+P % The literal P is a fact that can arrive.=P % The literal P is a fact that can arrive and that is removed.P % The literal P is a goal checked via backward chaining.

A surviving arriving fact itself is assumed via hypothetical reasoning. Extending the hypothet-ical reasoning therefore automatically extends the arriving facts that are understood by the annotations (+)/1 and (=)/1. The annotation (-)/1 and (=)/1 can be further extended by adding new clauses to the predicate sys_find_goal/4. The end-user needs to extend the predicate find_abnormal/1 as well, by patterns for the newly supported retract.

This Jekejeke Prolog module additionally provides the plus sign (+)/1 or equality sign (=)/1 not only as a literal annotation but also as a new constructor for hypothetical reasoning. Namely the embedded implication (=>)/2 and the (<=)/1 continuation variant will both trigger the forward chaining closure computation for facts that are wrapped in a plus sign (+)/1 or equality sign (=)/1. The computation iterates over delete set removal, surviving fact assump-tion and newly implied constructs:

Example:?- [user].q(X) <= =p(X).

Yes?- +p(Y) => q(X).Yes?- =p(Y) => q(X).X = Y

The following forward closure predicates are provided. The (delta) marking indicates that these predicates are only understood in the context of the right hand side of the forward chaining clause operator (<=)/2:

A, B (delta):The forward predicate reacts when either A or B react, and the other succeeds, or when both react. The predicate succeeds when A and B succeed.

-P (delta):The literal P is a fact from the database that is removed.

+P (delta):The literal P is a fact that can arrive.



=P (delta):The literal P is a fact that can arrive and that is removed.

P (delta):The literal P is a goal checked via backward chaining.

cosmetic P, ...:The predicate sets the predicate P to cosmetic.

forward P, ...:The predicate sets the predicate P to cosmetic and static.

sys_find_goal(T, B, R, G):The predicate succeeds for a goal G that searches the fact T and returns the body B and the reference R. The predicate is multi-file and can be extended by the end-user.

find_abnormal(A):The predicate succeeds for those retracts A that are extended in the (-)/1 or (=)/1 an-notation. The predicate is multi-file and can be extended by the end-user.

The following forward closure operators are provided The (hypo) marking indicates that these operators are only understood in the context of the left hand side of the hypothetical reason-ing operator (=>)/2 or in the right hand side of the (<=)/1 variant:

+P (hypo):The construct prevents that the literal P is directly assumed. Instead the literal P is treated as a fact that arrives in the forward chaining engine. Inter-clausal variables are not preserved by this construct.

=P (hypo):The construct prevents that the literal P is directly assumed. Instead the literal P is treated as a fact that arrives in the forward chaining engine. Inter-clausal variables in the literal P itself or in the triggered forward clauses are preserved by this construct.

H <= B:The construct defines a forward chaining clause with head H and body B. The clause is rewritten by the term expansion mechanism in possibly multiple ordinary clauses for possibly multiple delta predicates.

The following predicate properties for theory text are provided:

cosmetic:The property indicates that the predicate should be displayed as a forward predicate during debugging. The property can be changed for user predicates.



Module chartThis Jekejeke Minlog module allows executing definite clause grammars (DCGs) in a forward manner. The ordinary DCG rules of Jekejeke Prolog are not suitable for this purpose since they model terminals by [T|O] = I. We therefore provide special chart DCG rules as part of Jekejeke Minilog which model terminals by ‘D’(T,I), O is I+1. Chart DCG rules are identified by the (==>)/2 operator:

P ==> Q. % chart DCG rule with forward chaining.

Chart DCG rules do currently not allow for push backs. The term expansion augments the head and body by two additional parameters that are to represent the sentence position before and after the parsing. A predicate identifier p/n will thus be turned into a predicate identifier p/n+2. Further the DCG chart operator (==>)/2 is replaced by the forward chaining operator (<=)/2:

chart(P, I, O) <= sys_sys_chart(Q, I, O).

The term expansion will then go to work and tackle the head, whereas the goal expansion will tackle the body. Compared to ordinary DCG rules, the chart DCG rules support fewer cnstructs. For example we do not yet support the conditional (->)/2 and the higher order calls call/n. On the other hand we already support the grammar negation (\+)/1 and the forward chaining annotation (+)/1 is automatically placed:

Let’s consider the following example chart DCG rule:

p(X) ==> "a", q(X), {r(X)}. % chart DCG rule

As an intermediate results the chart DCG rule will be turned into:

+p(X, I, O) <= +'D'(97, I), {H is I+1}, q(X, H, O), {r(X)}.

The above rule will then be turned into a delta computation for the predicate ’D’/2. In general only the first literal of a DCG chart rule will be translated into a delta computation rule, improving efficiency. The chart/3 construct can also be used in hypothetical queries to generate the ‘D’/2 facts for a given sentence or in ordinary backward chaining query the result of parsing. See the palindrom example for more details.

The following chart parsing predicates are provided. The (chart) marking indicates that these predicates are only understood in the context of the right hand side of the chart rule operator (==>)/2:

chart(A, I, O):Succeeds when the phrase A starting with index I gives the remainder O.

chart(A, O):Succeeds when the phrase A starting with the first index gives the remainder O.

fail (chart):The grammar connective fails.

A, B (chart):The predicate reacts when either A or B react, and the other succeeds, or when both react. The predicate succeeds when A and B succeed. The output of A is conjoined with the input of B.



{A} (chart):The grammar connective succeeds whenever the goal argument A succeeds. The goal argument A is cut transparent and not chart translated.

\+ A (chart):When A succeeds, then the predicate fails. Otherwise the predicate succeeds. The second argument is left loose.

! (chart):The grammar connective removes pending choice and then succeeds once.

[A1, …, An] (chart):The grammar connective denotes terminals A1, …, An that can arrive.

P (chart):The literal is a fact that can arrive. The literal is augmented by two arguments.

The following chart parsing operators are provided. The (chart) marking indicates that these predicates are only understood in the context of the left hand side of the chart rule operators (==>)/2:

chart(A, I, O):Assumes that the phrase A starting with index I gives the remainder O.

chart(A, O):Assumes that the phrase A starting with the first index gives the remainder O.

[A1, …, An] (chart):The grammar connective directly assumes the terminals A1, …, An.

P (chart):The literal P is directly assumed. The literal is augmented by two arguments.

H ==> B:The construct defines a forward chart rule with chart head H and chart body B.



5.2 Term Domain PackageThis theory groups the predicates for constraint solvers over term domains. We find the fol-lowing topics:

Module herbrand: This module provides Herbrand constraints.

Module suspend: This module provides the delay of goals.



Module herbrandThis Jekejeke Minlog module provides a subject to occurs check constraint sto/1 and a term inequality constraint neq/2. To allow good performance both constraints perform an attribute variable verification before their attribute variables are instantiated and new sub constraints are registered:

Example:?- sto(X), X = f(X).No?- neq(f(X,X), f(Y,Z)), X = Y.Y = X,neq(X, Z)

The subject to occurs check has to be initially called with an acyclic term, but it will subse-quently assure the subject to occurs check as required. There is no interaction of the subject to occurs check with the term inequality, and the term inequality neither decided for or against the occurs check..

The following herbrand predicates are provided.

sto(T):The predicate continues the subject to occurs check for the term T. The term T has to be acyclic when calling this predicate.

neq(S, T):The predicate checks S and T for inequality and establishes variable constraints, so that this inequality is maintained in the continuation. The inequality neither decides for or against the occurs check.



Module suspendThis Jekejeke Minlog module provides the delay of goals until certain variable conditions are satisfied. The predicate freeze/2 delays until the first argument is instantiated. The predicate when/2 delays until the first argument succeeds.

Example:?- freeze(X, (write(foo), nl)).freeze(X, (write(foo), nl))?- freeze(X, (write(foo), nl)), X = a.fooX = a

The delayed goal is allowed to fail or to succeed multiple times. The when/2 predicate cur-rently understands as conditions conjunction (C1; C2), disjunction (C1; C2), variable instanti-ation nonvar(V) and ground-ness ground(V).

The following suspend predicates are provided:

freeze(V, G):If V is a variable further checks are delayed until the variable is instantiated with a non-variable or another variable. Otherwise the goal G is directly called.

when(C, G):If C simplifies to a non-trivial condition further simplifications are delayed until a varia-ble in C is instantiated with a non-variable or another variable. Otherwise the goal G is directly called.



5.3 Finite Domain PackageThis theory groups the predicates of the finite domain constraint solver. The finite domain constraint solver is available as a module clpfd. We find the following topics:

Integer Values: The finite domain solver allows denoting integer value expressions. These expressions can contain variables.

Integer Sets: The finite domain solver allows denoting integer set expressions. These expressions cannot contain variables.

Integer Comparison: As a convenience the finite domain solver provides a couple of comparisons between integers.

Boolean Values: As a further convenience we also provide reification.

Domain Search: Finally we provide a couple of solving techniques.



Integer ValuesThe finite domain solver allows denoting integer value expressions. These expressions can contain native Prolog variables. Integer expressions are posted to the finite domain solver viathe predicate #=/2. Internally integer equations are broken down into elementary integer equations with the help of new native Prolog variables. The resulting elementary integer equations are automatically shown by the top-level.

Example:?- X*Y*Z #= T._C*Z #= T,X*Y #= _C

Forward chaining rules and attribute variable hooks guard the interaction between the ele-mentary integer equations. A minimal logic reading of forward chaining rules with delete has been presented in [1]. It has also been shown there how forward chaining rules with delete can do simplifications if the constraint store is held in the forward store. Currently the follow-ing inference rule sets have been implemented for integer value expressions:

Forward Checking Duplicate Detection

The forward checking consists of the two inference rules constant elimination and constant back propagation, depending on whether the constants equations have first arrived in the forward store or the elementary integer equations. The forward checking also provides the inference rules of union find and variable renaming. Where permitted the #=/2 integer equa-tions are replaced by native Prolog unification. It is also allowed mixing native Prolog unifica-tion =/2 with integer equations:

Examples:?- X = Y, 4 #= X+Y.X = 2,Y = 2?- 4 #= X+Y, X = Y.X = 2,Y = 2

The duplicate detection has only been implemented for elementary integer equations that are the scalar product of a constant vector and a variable vector. The duplicate detection does not yet work for arbitrary products. It is handy in that it reduces the number of elementary equations and might also detect inconsistencies early on:

Examples:?- 2*X #= 4*Y, 3*X #= 6*Y.X #= 2*Y?- X #= Y+1, Y #= X+1.No

The following integer value expressions are provided:

I (finite):An integer I represents an integer constant.

V (finite):An native Prolog variable V represents an integer variable.



C (finite):A callable C is also a value expression.

A + B (finite):If A and B are value expressions then A+B is also a value expression.

A - B (finite):If A and B are value expressions then A-B is also a value expression.

- A (finite):If A is a value expression then -A is also a value expression.

A * B (finite):If A and B are value expressions then A*B is also a value expression.

abs(A) (finite):If A is a value expression then abs(A) is also a value expression.

The following integer value predicates are provided:

A #= B:If A and B are value expressions then their equality is posted.



Integer SetsSet expressions are posted via the predicate in/2 respectively ins/2 and are similarly handled to equality. Further forward checking and duplicate detection is also applied. But elementhood provides additional functionality. Namely we find the following additional inference rule for the element hood:

Interval Consistency

The interval consistency has been both implemented for the scalar product and multiplica-tion. A restricted form of interval consistency has been implemented. Namely intervals only propagate to the lexical head of a scalar product respectively multiplication. Directed interval consistency also works for the recently introduced abs/1 function.

Examples:?- X in 0..9, Y #= X+1, Z #= Y+1, X #= Z+1.Z #= X-1,Z in 2..8,...

?- X in 0..sup, Y #= X+1, Z #= Y+1, X #= Z+1.Z #= X-1,Z #> 1,...

This directed form of interval consistency is weaker than the full interval consistency. The directed form might accept equations that would otherwise be detected as inconsistent. But it has the advantage that it never loops and therefore also works for unbounded domains..

The following integer set expressions are provided:

I (finite):An integer I represents a singleton set {I}.

I..J (finite):If I and J are integers then the expression represents the interval [I..J]. It is also pos-sible that I takes the value inf or that J takes the value sup. The expression then de-notes the corresponding half interval or even the full integer domain.

A \/ B (finite):If A and B are set expressions then the union is also a set expression.

A /\ B (finite):If A and B are set expressions then the intersection is also a set expression.

\ A (finite):If A a set expressions then the complement is also a set expression.

The following integer value predicates are provided:

A in S:If A is a value expression and S is a set expression then the element hood is posted.

[A1, .., An] ins S:If A1, .., An are value expression and S is a set expression then the element hood is posted for each value expression.



Integer ComparisonAs a convenience the finite domain solver provides a couple of comparisons between inte-gers. The following features are provided in connection with integer comparison:

Constraint Factoring Global Constraints

Our finite domain solver is probably unique in that it allows posting element hood for arbitrary expressions. This feature is used to internally implement integer comparison. We find the usual comparisons such as #\=/2, #</2, #>/2, #=</2 and #>=/2. Comparisons are recon-structed from element hood when displaying constraints.

Example:?- Y - X in 0..sup.X #=< Y

The constraint solver also attempts to combine element hood constraints. Element hood constraints over the same expression are intersected similarly to domain constraints. Conse-quently comparisons can be contracted, subsumed or conflict. Also interaction with equations is possible, which are then treated as singleton element hood constraints.

Example:?- X #> Y, X #= Y.No

The integer comparisons can be used to define more complex conditions. A recurring prob-lem is stating the inequality of a couple of value expressions. The predicate all_different/2has been defined as a corresponding convenience.

Example:?- all_different([X,Y,Z]).Z #\= X,Z #\= Y,X #\= Y

The following integer comparison predicates are provided:

A #\= B:If A and B are value expressions then their inequality is posted.

A #< B:If A and B are value expressions then is posted that A is less than B.

A #> B:If A and B are value expressions then is posted that A is greater than B.

A #=< B:If A and B are value expressions then is posted that A is less or equal than B.

A #>= B:If A and B are value expressions then is posted that A is greater or equal than B.

all_different([A1, .., An]):If A1, .., An are value expressions then their inequality is posted.



Boolean ValuesAs a further convenience we also provide reification. Reification comes with a set of Boolean operators (#\)/1, (#\/)/2, etc.. and the possibility to embed membership (in)/2 and equalities respectively inequalities (#=)/2, (#>)/2, etc.. in Boolean expressions. The constraint solver main use case is as follows. The reified variable should on one hand allow firing the con-straint, but it should also reflect the entailed of the constraint.

Examples:?- X #< 100-Y #<==> B, B = 0.B = 0,X #> -Y+99

?- X #< 100-Y #<==> B, Y = 74, X = 25.X = 25,Y = 74,B = 1

Under the hood the reification is implemented via a couple of new guarded constraints. We find the guarded domain range, the guarded equality and the guarded membership. The lat-ter two guarded constraints are based on the scalar product. Each reified constraint is mod-elled by a pair of guarded constraints. At the moment only the main use case is implement-ed, so we don’t find yet interactions of the guarded constraints.

The following Boolean value predicates are provided:

A #==> B:If A and B are Boolean expressions then the implication is posted.

A #<== B:If A and B are Boolean expressions then the converse implication is posted.

A #<==> B:If A and B are Boolean expressions then the bi-implication is posted.

A #\/ B:If A and B are Boolean expressions then the disjunction is posted.

A #/\ B:If A and B are Boolean expressions then the conjunction is posted.

#\ A:If A is a Boolean expression then the negation is posted.



Domain SearchAs a convenience the finite domain solver provides a couple of solving techniques. We pro-vide the following solving techniques along domain ranges:

Heuristic Search

The constant values in the domain of a variable can be enumerated via the predicate indo-main/1. This predicate is capable of enumerating finite and infinite domains. For infinite do-mains it is also possible to enumerate domains that are open ended on both sides, resulting in an alternating enumeration towards inf and sup.

Examples:?- X in 10..15, indomain(X).X = 10 ;X = 11 ;...X = 15

?- indomain(X).X = 0 ;X = -1 ;X = 1 ;...

The only heuristic we have implemented so far is the fail-first search strategy. In certain cas-es this can reduce the search space. It can be invoked by the predicate label/1. Infinite do-mains are filtered out and cantor paired. Then smaller domains are enumerated first. Furthernotions of consistency and search are discussed in [2].

Examples:?- [X,Y] ins 0..9, 3*X+5*Y #= 11, label([X,Y]).X = 2,Y = 1 ;No

?- 3*X+5*Y #= 11, label([X,Y]).X = 2,Y = 1 ;X = -3,Y = 4 ;X = 7,Y = -2 ;...

The following domain search predicates are provided:

indomain(V):The predicate succeeds for every element in the domain of the variable V and instan-tiates the variable V with this element. The domain of the variable can be finite or infi-nite. A missing domain is interpreted as the full domain.

label([V1, .., Vn]):The predicate post all the assignments of constants I1, .., In to the variables V1, .., Vnfrom their domains. Infinite domains are filtered out and cantor paired. Then smaller domains are enumerated first.



5.4 Miscellaneous PackageThis theory is concerned with miscellaneous predicates. The predicates mainly deliver addi-tional operations for the standard Prolog data types. These operations might be useful when implementing chart parsers, constraint solvers, etc..

Elementary Extensions: We provide a couple of additional elementary operations.

Bitwise Extensions: We provide a couple of additional bitwise operations.

Structure Extensions: We provide a couple of additional structure predicates.



Elementary ExtensionsWe provide a couple of additional elementary operations. The ulp operation is defined for integer, float and decimal. It returns a result of the same type as its argument. The gcd oper-ation is currently only defined for integers. It returns a result that is an integer:

ulp: integer -> integerulp: float -> floatulp: decimal -> decimalgcd: integer x integer -> integer

The ulp operation makes use of the ulp() function of the Java Math library. The gcd operation implements a binary gcd algorithm for 32-bit integers and otherwise delegates to the Java BigInteger gcd operation implementation.

Examples:ulp(0) --> 1ulp(0.0) --> 4.9E-324ulp(0d0.00) --> 0d0.01gcd(36,24) --> 12

The following elementary evaluable functions are provided:

ulp(X):Returns the unit of least precision of the number X.

gcd(X, Y):Returns the greatest common divisor of the integer X and the integer Y.



Bitwise ExtensionsWe provide a couple of additional bitwise operations. The evaluable functions bitcount/1, bitlength/1 and lowestsetbit/1 deal with the determination of certain bits of the given integer. The evaluable functions setbit/2 and clearbit/2 update the given integer in a more efficient way than would be possible with existing logical and shift operations.

The predicate sys_test_bit/2 tests a particular bit in a given integer, again the implementation is more efficient than would be possible with existing logical, shift and test operations.

The following bitwise evaluable functions are provided:

bitcount(X):If X is an integer returns the number of non-zero bits.

bitlength(X):If X is an integer returns the index of the highest non-zero bit.

lowestsetbit(X):If X is an integer returns the index of the lowest non-zero bit.

setbit(X, Y):If X and Y are integers returns Y with the bit at index X set.

clearbit(X,Y):If X and Y are integers returns Y with the bit at index X cleared.

The following built-in predicates are provided for bitwise extensions. The built-ins arithmeti-cally evaluate their arguments before performing their tests:

sys_test_bit(X, Y):Succeeds when Y has the bit at index X set, otherwise fails.



Structure ExtensionsWe provide a couple of additional variables predicates. Prolog already provides an existential quantification operator in the form of (^)/2. This operator is only needed in certain circum-stance such as the frequent predicates from the module abstract or the module bags.

Examples:?- sys_term_kernel(X#p(X,Y),K).K = p(X,Y)?- sys_term_globals(X#p(X,Y),L).L = [Y]

We introduce a further operator. We use the form (#)/2 for the universal quantification opera-tor. For performance reasons we have introduced the predicates sys_term_kernel/2 and sys_term_globals/2 which are the analogues to the corresponding goal predicates.

The following variable predicates are provided:

sys_term_kernel(G, K):The predicate succeeds when K unifies with the kernel of the goal G.

sys_term_globals(G, L):The predicate succeeds when L unifies with the global variables of the goal G.



5.5 System PackageThis theory is concerned with accessing the Prolog system. Internally the forward chaining component uses clause references to undo insertions and removals.

Attribute Variables: Attribute variables trigger during unification.

Trailed Updates: Clauses can be temporarily asserted or retracted.

Continuation Queue: Goals can be pushed on the continuation queue.

Micro Engines: Goals can be executed inside micro engines.

Attribute VariablesAttribute variables trigger during unification. From the viewpoint of the interpreter attribute variables are simply variables. The main functionality is that binding an attribute variable trig-gers the hooks that are associated with the attribute variable. If a hook fails the unification fails. If a hook succeeds the binding effects of the hook are kept.

Example:hook(V, T) :-

write('bind '), write(V), write(' to '), write(T), nl.

A hook is just a closure that takes the attribute variable and the term that is attempted to uni-fy with the attribute variable. It can be compiled with the predicate sys_compile_hook/3. The resulting reference can be recorded and erased like a clause reference. The hooks of a vari-able can be enumerated via the predicate sys_clause_hook/3.

Example:?- sys_compile_hook(V, hook, R),

recordz_ref(R), V = 99.bind _A to 99V = 99.

In contrast to ordinary variables, attribute variables are reordered during unification so that two attribute variables are only unified as a last resort. As a result attribute variables are less often instantiated than ordinary variables. The predicate sys_ensure_serno/1 can be used to force the assignment of a serial number. The serial number of a variable is used in writing and lexical comparison.

The following attribute variable predicates are provided:

sys_ensure_serno(V):The predicate promotes the first argument to an attribute variable when V is an ordi-nary variable. The predicate then ensures that the first argument has a serial number.

sys_compile_hook(V, H, R):The predicate promotes the first argument to an attribute variable when V is an ordi-nary variable. The predicate then succeeds when the compiled reference of the hook H unifies with R.

sys_clause_hook(V, H, R):



The predicate fails when V is an ordinary variable. Otherwise the predicate succeeds for each hook H and reference R that unifies with the hooks and references of the at-tribute variable V.



Trailed UpdatesThe system predicate sys_unbind/1 installs an unbind handler and immediately succeeds. The unbind handler is invoked during a redo or a close. In contrast to a cutter the unbind handler is not invoked when choice points are removed. When the unbind handlers are exe-cuted exceptions are accumulated that are possibly thrown by the unbind handlers. When unbind handler fails a directive failed error is thrown.

The predicate sys_freeze_var/2 will create a new reference object that captures the given variable. The reference object will have a stable hash, equal and lexical ordering for the du-ration of the continuation. The predicate sys_melt_var/2 allows retrieving the term the varia-ble is currently instantiated to. The predicate sys_bound_var/1 allows checking whether the variable is currently instantiated or not.

The following trailed update predicates are provided:

sys_unbind(A):The predicate installs an unbind handler A and immediately succeeds. The unbind handler is invoked during a redo or a close.

sys_freeze_var(V, R):The predicate succeeds when R unifies with a new references object that captures the variable V.

sys_melt_var(R, T):The predicate succeeds when T unifies with what the variable captured by the refer-ence object R is currently instantiated.

sys_bound_var(R):The predicate succeeds when the variable captured by the reference object R is cur-rently instantiated.



Continuation QueueThis module allows accessing the continuation queue and the verify flag. New goals can be pushed and popped from the continuation queue via the predicates cont_push/1 and cont_pop/0. The predicate sys_ripple/1 allows disabling the verify flag during the execution of a goal.

It is recommended to push a delayed goal by the predicate sys_assume_cont/1 from the module assume. This predicate will also place an undo handler on the trail that will pop thedelayed goal upon backtracking.

When the verify flag allows it the whole continuation queue is executed either on the next exit port of a built-in or the next unification port of a defined predicate. The verify flag is automati-cally disabled during execution of attribute variable hook.

The following continuation queue predicates are provided:

cont_push(G):The predicate pushes the goal G on the continuation queue.

cont_pop:The predicate pops a goal from the continuation queue.

sys_ripple(A):The predicate succeeds whenever A succeeds. The goal A is invoked with the verify flag temporarily set to off.

The following Prolog flags for continuation queue are provided:

sys_verify:Legal values are on and off. The flag indicates whether the interpreter currently executes continuations. Default value is on. The value can be changed.



6 Appendix Example ListingsThe full source code of the Jekejeke Minlog module examples is given. The following source code has been included:

Bonner’s Examples Animals Revisited Palindrome Revisited Money Revisited Little Solver Tracing Revisited Subject to Occurs Check

6.1 Bonner’s ExamplesFor the Bonner’s examples there are the following sources:

grade.p: The Prolog text of the embedded implication example. grade2.p: The Prolog text of the embedded contraction example.

Prolog Text grade/*** Bonner's first hypothetical reasoning example.** Copyright 2011-2014, XLOG Technologies GmbH, Switzerland* Jekejeke Minlog 0.6.2 (minimal logic extension module)*/

:- use_module(library(minimal/assume)).:- use_module(library(system/ref)).

:- op(1200, xfx, -:).:- meta_predicate (-1 -: 0).

/* embedded implication */(A -: B) :-

consultable_ref(A, R),sys_assume_ref(R),call(B),sys_retire_ref(R).

/* student must take german and can choose between french and italian */grade(S) :- take(S, german), take(S, french).grade(S) :- take(S, german), take(S, italian).

/* hans has already taken french */take(hans, french).

% /* hans would not grade if he takes also italian */% ?- take(hans, italian) -: grade(hans).% No

% /* hans would grade if he takes also german */% ?- take(hans, german) -: grade(hans).% Yes ;% No





Prolog Text grade2/*** Bonner's second counter factual example.** Copyright 2011-2014, XLOG Technologies GmbH, Switzerland* Jekejeke Minlog 0.6.2 (minimal logic extension module)*/

:- use_module(library(minimal/assume)).

:- op(1200, xfx, \:).:- meta_predicate (-1 \: 0).

/* embedded contraction */(A \: B) :-

sys_clause_ref(A, true, R),sys_retire_ref(R),call(B),sys_assume_ref(R).

/* student must take german and can choose between french and italian */grade(S) :- take(S, german), take(S, french).grade(S) :- take(S, german), take(S, italian).

/* hans has already taken german, french and italian*/take(hans, german).take(hans, french).take(hans, italian).

% /* hans would still grade if he would not have taken italian */% ?- take(hans, italian) \: grade(hans).% Yes ;% No

% /* hans would not grade if he would not have taken german */% ?- take(hans, german) \: grade(hans).% No



6.2 Animals RevisitedFor the animals revisited there is the following source:

animals3.p: The Prolog text.

Prolog Text animals3/*** Prolog code for the revisited logic example.** Copyright 2012-2014, XLOG Technologies GmbH, Switzerland* Jekejeke Minlog 0.5 (minimal logic extension module)*/

:- use_module(library(minimal/delta)).

:- thread_local motion/1, skin/1, diet/1, class/1, animal/1.:- forward motion/2, skin/2, diet/2, class/2, animal/2.

+class(mamal) <= +motion(walk), +skin(fur).+class(fish) <= +motion(swim), +skin(scale).+class(bird) <= +motion(fly), +skin(feather).

+animal(rodent) <= +class(mamal), +diet(plant).+animal(cat) <= +class(mamal), +diet(meat).+animal(salmon) <= +class(fish), +diet(meat).+animal(eagle) <= +class(bird), +diet(meat).

% ?- use_module(library(minimal/hypo)).

% ?- <= +motion(walk), <= +skin(fur), <= +diet(meat), animal(X).% X = cat

% ?- animal(X).% No

% ?- <= +diet(meat), <= +skin(fur), <= +motion(walk), animal(X).% X = cat



6.3 Palindrome RevisitedFor the palindrome revisited there is the following source:

palin3.p: The Prolog text.

Prolog Text palin3/*** Prolog code for the revisited DCG with attributes example.** Warranty & Liability* To the extent permitted by applicable law and unless explicitly* otherwise agreed upon, XLOG Technologies GmbH makes no warranties* regarding the provided information. XLOG Technologies GmbH assumes* no liability that any problems might be solved with the information* provided by XLOG Technologies GmbH.** Rights & License* All industrial property rights regarding the information - copyright* and patent rights in particular - are the sole property of XLOG* Technologies GmbH. If the company was not the originator of some* excerpts, XLOG Technologies GmbH has at least obtained the right to* reproduce, change and translate the information.** Reproduction is restricted to the whole unaltered document. Reproduction* of the information is only allowed for non-commercial uses. Selling,* giving away or letting of the execution of the library is prohibited.* The library can be distributed as part of your applications and * libraries for execution provided this comment remains unchanged.** Trademarks* Jekejeke is a registered trademark of XLOG Technologies GmbH.*/

:- use_module(library(minimal/chart)).:- use_module(library(experiment/ref)).

:- static palin/5.

palin([], [Middle]) ==>[Middle].

palin([Middle], []) ==>[Middle, Middle].

palin([Border | List], Middle) ==>[Border], palin(List, Middle), [Border].


% ?- <= chart("bert", _), listing('D'/2).% :- thread_local 'D'/2.% 'D'(116, 3).% 'D'(114, 2).% 'D'(101, 1).% 'D'(98, 0).

% ?- <= chart("racecar", N), chart(palin(X1,Y1), N).% X1 = [114,97,99],% Y1 = [101]



% ?- <= chart("bert", N), chart(palin(X1,Y1), N).% No



6.4 Money RevisitedFor the money revisited there is the following source:

money3.p: The Prolog text.

Prolog Text money3/*** Prolog code for the revisited backtracking example.** Puzzle originally published July 1924 issue of* Strand Magazine by Henry Dudeney** Copyright 2012-2014, XLOG Technologies GmbH, Switzerland* Jekejeke Minlog 0.5 (minimal logic extension module)*/

:- use_module(library(finite/clpfd)).

% puzzle(-List)puzzle(X) :-

X = [S,E,N,D,M,O,R,Y],X ins 0..9,all_different(X),M #\= 0,S #\= 0,

1000*S + 100*E + 10*N + D +1000*M + 100*O + 10*R + E #=

10000*M + 1000*O + 100*N + 10*E + Y,label(X).

% ?- puzzle(Z).% Z = [9,5,6,7,1,0,8,2] ;% No



6.5 Little SolverFor the little solver there is the following source:

domain.p: The Prolog text.

Prolog Text domain/*** Prolog code for the little solver.** Copyright 2012-2013, XLOG Technologies GmbH, Switzerland* Jekejeke Minlog 0.6 (minimal logic extension module)*/

:- use_module(library(minimal/delta)).:- use_module(library(basic/lists)).:- use_module(library(advanced/sets)).

% bound(+Atom, +Elem):- thread_local bound/2.

unit <= =bound(X, Y), bound(X, Z), Y = Z, !.zero <= +bound(X, _), bound(X, _).

% domain(+Atom, +List):- thread_local domain/2.

zero <= +domain(_, []), !.+bound(X, Y) <= =domain(X, [Y]), !.unit <= =domain(X, A), +bound(X, Y), member(Y, A), !.zero <= +domain(X, _), +bound(X, _).+domain(X, C) <= =domain(X, B), -domain(X, A), intersection(A, B, C).

% ?- use_module(library(minimal/hypo)).% Yes

% ?- <= +domain(x,[1]), listing(bound/2), listing(domain/2).% bound(x, 1).% Yes

% ?- <= +domain(x,[1,2,3]), <= +domain(y,[2,3,4]),listing(bound/2), listing(domain/2).

% domain(x, [1,2,3]).% domain(y, [2,3,4]).% Yes

% ?- <= +domain(x,[1,2,3]), <= +domain(x,[2,3,4]),listing(bound/2), listing(domain/2).

% domain(x, [2,3]).% Yes

% ?- <= +domain(x,[1,2,3]), <= +bound(x,4),listing(bound/2), listing(domain/2).

% No



6.6 Tracing RevisitedFor the tracing revisited there is the following source:

trace3.p: The Prolog text.

Prolog Text trace3/*** Prolog code for the revisited trace example.** Copyright 2012-2014, XLOG Technologies GmbH, Switzerland* Jekejeke Minlog 0.6.2 (minimal logic extension module)*/

:- use_module(library(minimal/delta)).

:- thread_local p/0, r/0, q/0, s/0.:- forward p/1, r/1, q/1, s/1.

+r <= +p.+q <= +p.+s <= +q, +r.


% ?- <= +p, s.% Yes

% ?- trace.% Yes

% ?- <= +p, s.% 0 Call post(p) ?% 1 Post p ?% Etc..



6.7 Subject to Occurs CheckFor the subject to occurs check there are the following sources:

typed.p: The Prolog text for the type inference without subject to occurs check. typed2.p: The Prolog text for the type inference with subject to occurs check.

Prolog Text typed/*** Prolog code for the type inference * without subject to occurs check.** Copyright 2013-2014, XLOG Technologies GmbH, Switzerland* Jekejeke Minlog 0.6.6 (minimal logic extension module)*/

:- use_module(library(experiment/pairlist)).

/*******************************************************//* Type Inference for Simple Types *//*******************************************************/

% typed(+Expression, +Context, -Type)typed(X, C, T) :- var(X), !, lookup_eq(C, X, T).typed(lam(X,E), C, (S->T)) :- typed(E, [X-S|C], T).typed(app(E,F), C, T) :- typed(E, C, (S->T)), typed(F, C, S).

% ?- typed(app(E,F), [E-A,F-B], C).% A = (B->C)

% ?- typed(app(F,F), [F-A], B).% A = (A->B) or crash, both undesired

% ?- typed(lam(X,lam(Y,app(Y,X))), [], A).% A = (_C->(_C->_I)->_I

Prolog Text typed2/*** Prolog code for the type inference* with subject to occurs check.** Copyright 2013-2014, XLOG Technologies GmbH, Switzerland* Jekejeke Minlog 0.6.6 (minimal logic extension module)*/

:- use_module(library(experiment/pairlist)).:- use_module(library(term/herbrand)).

/*******************************************************//* Type Inference for Simple Types *//*******************************************************/

% typed(+Expression, +Context, -Type)typed2(X, C, T) :- var(X), !, lookup_eq(C, X, T).typed2(lam(X,E), C, (S->T)) :- typed2(E, [X-S|C], T).



typed2(app(E,F), C, T) :- sto(S), typed2(E, C, (S->T)), typed2(F, C, S).

% ?- sto((A,B,C)), typed2(app(E,F), [E-A,F-B], C).% A = (B->C),% sto(C),% sto(B)

% ?- sto((A,B)), typed2(app(F,F), [F-A], B).% No

% ?- sto(A), typed2(lam(X,lam(Y,app(Y,X))), [], A).% A = (_A->(_A->_B)->_B,% sto(_B),% sto(_A)



Indexes

Public PredicatesPredicate Module#/\ /2 finite/reify#< /2 finite/clpfd#<== /2 finite/reify#<==> /2 finite/reify#= /2 finite/linform#=< /2 finite/clpfd#==> /2 finite/reify#> /2 finite/clpfd#>= /2 finite/clpfd#\ /1 finite/reify#\/ /2 finite/reify#\= /2 finite/clpfd(+)/1 minimal/delta(+)/3 minimal/chart(-)/1 minimal/hypo--: /2 minimal/chart<= /1 minimal/hypohypo: <= /1 minimal/deltahypo: <= /1 minimal/chart<= /2 minimal/delta= /1 minimal/delta==> /2 minimal/chart=> /2 minimal/hypohypo: => /2 minimal/deltahypo: => /2 minimal/chartall_different/1 finite/clpfdbitcount/2 misc/bitsbitlength/2 misc/bitschart/2 minimal/chartchart/3 minimal/chartclearbit/3 misc/bitscosmetic/1 minimal/deltadelta_abnormal/1 minimal/deltaforward/1 minimal/deltafreeze/2 term/suspendgcd/3 misc/elemuser:goal_expansion/2 minimal/chartuser:goal_exposing/3 minimal/deltahypo_abnormal/1 minimal/hypohypo:hypo_abnormal/1 minimal/deltahypo:hypo_abnormal/1 minimal/chartin/2 finite/intsetindomain/1 finite/intsetins/2 finite/intsetlabel/1 finite/clpfdlast_atom_concat/3 misc/atomlast_sub_atom/4 misc/atomlast_sub_atom/5 misc/atomlowercase/2 misc/charlowestsetbit/2 misc/bits



minus_abnormal/1 minimal/hyponeq/2 term/herbrandsetbit/3 misc/bitssto/1 term/herbrandsys_assume_cont/1 minimal/assumesys_assume_ref/1 minimal/assumesys_bound_var/1 experiment/trailsys_clause_hook/3 experiment/attrsys_compile_hook/3 experiment/attruser:sys_current_eq/2 term/herbranduser:sys_current_eq/2 term/suspenduser:sys_current_eq/2 finite/clpfdsys_ensure_hook/2 minimal/assumesys_ensure_hook/3 minimal/assumesys_ensure_serno/1 experiment/attrsys_find_goal/4 minimal/deltasys_freeze_var/2 experiment/trailsimp:sys_goal_simplification/2 minimal/deltasys_melt_var/2 experiment/trailsys_pop_cont/0 experiment/contsys_post_goal/3 minimal/deltasys_push_cont/1 experiment/contsys_ref_eq/2 finite/clpfdsys_retire_ref/1 minimal/assumesys_ripple/1 experiment/contsys_term_globals/2 misc/strucsys_term_kernel/2 misc/strucsimp:sys_term_simplification/2 minimal/deltasys_test_bit/2 misc/bitssys_unbind/1 experiment/trailuser:sys_unwrap_eq/2 term/herbranduser:sys_unwrap_eq/2 term/suspenduser:sys_unwrap_eq/2 finite/clpfduser:term_expansion/2 minimal/deltauser:term_expansion/2 minimal/chartulp/2 misc/elemuppercase/2 misc/charwhen/2 term/suspendzero/0 minimal/hypo

Package Local PredicatesPredicate Modulesys_abs_range/2 finite/intsetsys_absv/2 finite/clpfdsys_absv/3 finite/clpfdsys_add_prod/3 finite/linformsys_add_range/3 finite/intsetsys_add_set/3 finite/intsetsys_bisect/4 finite/intsetsys_blur_range/3 finite/intsetsys_bound_set/2 finite/intsetsys_card_set/2 finite/intsetsys_comp_set/2 finite/intset



sys_conc_range/2 finite/intsetsys_cross_range/3 finite/intsetsys_div_prod/3 finite/linformsys_div_range/3 finite/intsetsys_div_set/3 finite/intsetsys_elem_set/2 finite/intsetsys_expr_set/2 finite/intsetsys_flip_prod/2 finite/linformsys_flip_range/2 finite/intsetsys_flip_set/3 finite/intsetsys_fresh_var/2 finite/linformsys_gcd_prod/2 finite/linformsys_hook/2 finite/clpfdsys_in/3 finite/clpfdsys_in/4 finite/clpfdsys_inter_range/3 finite/intsetsys_inter_set/3 finite/intsetsys_invabs_range/2 finite/intsetsys_lin/2 finite/clpfdsys_lin/3 finite/clpfdsys_make_prod/4 finite/linformsys_mem_set/2 finite/intsetsys_mul_prod/3 finite/linformsys_mulv/3 finite/clpfdsys_mulv/4 finite/clpfdsys_prem_range/2 finite/intsetsys_pretty_lin/3 finite/linformsys_pretty_set/2 finite/intsetsys_pump_range/3 finite/intsetsys_root_range/2 finite/intsetsys_set/2 finite/clpfdsys_set/3 finite/clpfdsys_slash_range/3 finite/intsetsys_square_range/2 finite/intsetsys_value_expr/3 finite/linformsys_value_expr_inv/3 finite/linform

Non-Private Meta-PredicatesPredicate Exp Body Rule Module+0 yes no no minimal/delta- 0 yes no no minimal/hypo<=(-1) yes no no minimal/hypohypo: <=(-1) yes no no minimal/deltahypo: <=(-1) yes no no minimal/chart<=(0,-1) yes no no minimal/delta=(0) yes no no minimal/delta=>(-1,0) yes no no minimal/hypohypo: =>(-1,0) yes no no minimal/deltahypo: =>(-1,0) yes no no minimal/chartcosmetic(0) yes no no minimal/deltaforward(0) yes no no minimal/deltafreeze(?,0) yes no no term/suspenduser:goal_expansion(0,0) no no no minimal/chart



user:sys_current_eq(?,0) yes no no term/herbranduser:sys_current_eq(?,0) yes no no term/suspenduser:sys_current_eq(?,0) yes no no finite/clpfdsimp:sys_goal_simplification(0,0) no no no minimal/deltasys_push_cont(0) yes no no experiment/contsys_ref_eq(?,0) yes no no finite/clpfdsys_ripple(0) yes no no experiment/contsimp:sys_term_simplification(-1,-1) no no no minimal/deltasys_unbind(0) yes no no experiment/trailuser:sys_unwrap_eq(0,0) yes no no term/herbranduser:sys_unwrap_eq(0,0) yes no no term/suspenduser:sys_unwrap_eq(0,0) yes no no finite/clpfduser:term_expansion(-1,-1) no no no minimal/deltauser:term_expansion(-1,-1) no no no minimal/chartwhen(?,0) yes no no term/suspend

Non-Private Closure-PredicatesPredicate Module+(2,?,?) minimal/chart--:(2,-3) minimal/chart==>(2,-3) minimal/chartchart(2,?) minimal/chartchart(2,?,?) minimal/chartsys_clause_hook(?,2,?) experiment/attrsys_compile_hook(?,2,?) experiment/attrsys_ensure_hook(?,2) minimal/assumesys_ensure_hook(?,2,0) minimal/assume

Non-Private Syntax OperatorsLevel Mode Operator Module1200 xfx <= minimal/delta1200 xfx --: minimal/chart1200 xfx ==> minimal/chart1150 fy forward minimal/delta1150 fy cosmetic minimal/delta760 xfx #<== finite/reify760 xfx #<==> finite/reify760 xfx #==> finite/reify740 yfx #\/ finite/reify720 yfx #/\ finite/reify700 fx <= minimal/hypo700 fy #\ finite/reify700 xfx #< finite/clpfd700 xfx #> finite/clpfd700 xfx #>= finite/clpfd700 xfx #\= finite/clpfd700 xfx #= finite/linform700 xfx in finite/intset700 xfx => minimal/hypo



700 xfx ins finite/intset700 xfx #=< finite/clpfd200 fy = minimal/delta100 fx .. finite/intset100 xfx .. finite/intset100 xf ... finite/intset



Pictures

Figure 1: Forward Debugging Ports......................................................................................21

Tables

Table 1: Predefined Syntax Operators..............................Fehler! Textmarke nicht definiert.Table 2: Predefined Meta-Predicates and Rewriting Properties........Fehler! Textmarke nicht

definiert.Table 3: Predefined Closure Arguments...........................Fehler! Textmarke nicht definiert.

References

[1] Burse, J. (2012): Bedeutungsextraktion als Deduktion, Präsentation an der 22. Ta-gung der Computerlinguistik-Studierenden, June, 2012, University Trier, Germanhttp://www.xlog.ch/webapps/sitetab/doclet/en/docs/1_newsandevents/2_events/098_tacos/package.html

[2] Apt, K.R. (2003): Principles of Constraint Programming, Cambridge University Press, 2003

[3] Bonner, A.J. (1988): A Logic for Hypothetical Reasoning, Technical Report DCS-TR-230, Department of Computer Science, Rutgers University, August, 1988http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.1451

[4] Bonner, A.J. (1990): Hypothetical Datalog: Complexity and Expressibility, Theoretical Computer Science, 76:3-51, 1990http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.47.8941

[5] Halpern , J. (1999): Hypothetical Knowledge and Counterfactual Reasoning, Interna-tional Journal of Game Theory, 28:315-330, 1999http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.7343

[6] Lindgren, T. (1994): A Continuation-Passing Style for Prolog, International Symposi-um on Logic programming, 603-617, 1994http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.49.3062

http://www.xlog.ch/webapps/sitetab/doclet/en/docs/1_newsandevents/2_events/098_

http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.56.1451

http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.47.8941

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.7343

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.49.3062

Documents

Jekejeke Minlog Reference