5.2 Extensions of the Constraint Language
5.3.1 Control Information
5.3.1.1 Clause Types
The most important kind of control information concerns the question of what a clause should be compiled into. This is indicated by the main connective that links the consequent and the antecedent of the clause (cf. figure 5.7).
Clause Type Syntax Prolog clause C:-A.
GeLD clause C<-A.
Macro C<=A.
Fact C.
Figure 5.7: Clause types
The choice of a clause type determines how the clause is processed. The four classes have the following appropriate uses:
Prolog clause: Prolog clauses are compiled directly into Prolog clauses, although some of their goals may be expanded by partial deduction. They can later only be executed directly by Prolog, which is in certain cases more efficient than use of a deduction system implemented on top of Prolog, but suffers from the usual problems of Prolog’s search strategy. Goals in a Prolog clause can be passed to the GeLD system for an alternative deduction strategy. Pro-log clauses are primarily intended for calling externally defined procedures, and for side effects.
GeLD clause: GeLD clauses are compiled into a form that can be interpreted by the deduction system described below. If a GeLD clause has an empty body (usually as the result of partial deduction), it is compiled into a Prolog fact in order to gain efficient access to it through Prolog’s indexing mechanisms.
This is especially important in order to ensure efficienct access to large data bases, e.g. lexicons with thousands of entries.
Macro: A “macro” is a clause that is used during the partial deduction phase, but for which no representation is created in the target file. This not only avoids redundant code in the target file, but also allows the expansion of recursive macros, provided that their relevant variables are properly instantiated.
Fact: Clauses without goals (possibly as the result of partial deduction) are always compiled into Prolog facts, since obviously they need not contain any control information, but are trivially provable. The compilation into Prolog facts is used to make the Prolog compiler perform indexing on these clauses, so that even large databases of facts can be efficiently accessed.
This distinction into several clause types allows a proper division of labour be-tween those clauses which can easily be handled by Prolog (and benefit of efficient compilation) and those that need the deduction system as a meta-interpreter.
5.3.1.2 Goal Types
A goal in the body of a clause can be annotated with control information (goal type) that specifies how it should be executed. A goal type is specified by a one-letter code which is prefixed to the goal. A list of possible goal types is given in figure 5.8.
The significance of each goal type is explained below:
c: chart-based processing. This option refers to the bottom-up Earley deduc-tion developed in chapter 3. A new chart is created for proving the goal.
d: top-down processing. This option is like Prolog’s proof strategy, but a meta-interpreter is used instead. This option should be chosen if goals other than Prolog goals can occur in the proof of the goal.
Code Goal Type
c chart-based processing d top-down goal
e (top-down)Earley deduction h Head-driven processing
i immediate execution m macro
p Prolog goal w waiting goal
Figure 5.8: Goal types
e: (top-down) Earley deduction. These goals are executed by the classic top-down Earley deduction algorithm. A new chart is created for the proof of ane-goal.
i: immediate execution. i goals are executed immediately at compile time by calling them as Prolog goals. This is a form of partial deduction:igoals never appear in the output of the partial deduction; instead there will be a number of new clauses, depending on how many solutions thei-goal has. i-goals are used for calling Prolog built-in predicates or predicates of a program that has previously been consulted.7
m: macro. These goals are replaced in a partial deduction step. An m-goal is matched against clauses (of the same program) with the same predicate in their consequent, and replaced by the goals in the antecedents of these clauses. If the goals in these clauses contain againmori-goals, the process is applied recursively. It is possible that the goal completely disappears in the process by being (successively) replaced by the empty body.
p: Prolog goal. Prolog goals are executed directly by Prolog at runtime. Clauses for goals that are called as Prolog goals should be either Prolog built-in predicates or specified as Prolog clauses.
h: head-driven goal. These goals are executed according to a head-driven stra-tegy.
w: waiting goal. A waiting goal is one thatwaitsto be combined with a passive item in the course of (bottom-up or top-down) Earley deduction, or with the result of a bottom-up deduction step in head-driven processing. When a waiting goal is encountered in the proof of a goal, its clause is turned into
7Some Prolog systems make a distinction betweenconsultingandcompiling, where the latter is more efficient. When the termconsult is used in this chapter, we generally mean the loading of Prolog clauses by the most efficient method available.
GeLD Goals
Compile time goals Runtime goals
Immediate execution
m Macro Provable Goal w Waiting goal
Backward chaining Forward chaining
d top-down e Earley deduction Prolog goal
h head-driven c chart goal p
i
Figure 5.9: Hierarchy of goal types
an active item. Any clauses whose first goal is a waiting goal are turned into items at compile time.
These goal types can be divided into those which are used at compile time (iand m) and the others which are used at runtime. The runtime goals can be divided into waiting goals (w) which are passive and activated in Earley deduction or head-driven processing, and provable goals, for which proof procedures are implemented in the system. The provable goals are further subdivided into backward chaining (top-down) goals (d,eandp) and forward chaining (bottom-up) goals (candh).
This hierarchy of goal types is shown in figure 5.9.
In addition to goal types for individual goals, it is possible to specify a default goal type for each predicate. This default will be used for every goal which is not given an explicit goal type. The notation for the specification of a default is the following:
:- goal_type(Functor/Arity,Type).
The following directives specify that the default goal type forsign/1iswand forhead feature principle/1ism.
:- goal_type(sign/1,w).
:- goal_type(head_feature_principle/1,m).
If there is no goal type and no default for a goal in a clause, then it becomes ap goal. This is in accordance with the strategy to use execution by Prolog whenever possible for reasons of efficiency.
There is a restriction for the goal types in the body of a Prolog clause or a macro: they must not contain any waiting goals.
5.3.1.3 Base Case Lookup
In order to provecandhgoals by means of forward chaining, the deduction system must know which base cases of recursively defined predicates to use for a given goal. For example, for computing the factorial function bottom-up, the base case should always be the factorial of 0. For linguistic deduction, the base cases should for example be the lexical entries of the words contained in a string to be parsed, or a non-chain rule having the same semantics as a sign to be generated.
At present, we have no general method for determining the appropriate base cases for given goals. Therefore, the user must specify which base case is appropri-ate for which goal. This is done by providing clauses for the relationlookup/3for head-driven processing, and forlookup/4 for bottom-up Earley deduction. The prodcures lookup/3 and lookup/4have the following arguments (the first three are shared).
1. The first argument is the goal to be proven.
2. The second argument is the base case that is used to start a bottom-up proof of the goal.
3. The third argument is the goal type according to which the base case is proven. If the base case must simply be looked up as a fact, then it can be specified as ap-goal.
4. The extra fourth argument in the case of bottom-up Earley deduction is the index of the passive item that is created as the result of base case lookup.
Figure 5.10 shows a specification of the lookup relation for bottom-up Earley deduction (based on the specification of the lookup relation in figure 3.5).
Assuming that the derivation via a chain rule or a non-chain rule is encoded in a sign as the value of the featurederiv, the following is the lookup relation for semantic-head driven generation (goal type: h).
lookup(sign(sem!Sem), sign(sem!Sem & deriv!non chain), d). (5.10) 5.3.1.4 Priorities
The goals in the body of the clause can be given a numerical priority which deter-mines the order in which they are processed. This is merely a notational conve-nience which makes re-ordering goals easier than cut-and-paste which always leads into trouble when the last goal of the clause is affected.
Goals without a priority are assumed to have the priority 0.
lookup(sign(phon!PhonList),
lexical sign(phon![Word] & synsem!X ), d,
Begin-End )
<-nth member(Word,Begin,End,PhonList), lexicon(Word,X).
nth member(X,0,1,[X|]).
nth member(X,N1,N2,[|R]) <-nth member(X,N0,N1,R), N2 is N1 + 1.
Figure 5.10: Specification of the relationlookup in GeLD