| ?- show_clause append.
HEAD: append(e_list,
[0] bot,
[0] )
BODY: true
ANOTHER? y.
HEAD: append(ne_list_quant
HD [0] quant
RESTR proposition
SCOPE proposition
VAR individual
TL [1] list_quant,
[2] bot,
ne_list_quant
HD [0]
TL [3] list_quant)
BODY: append([1],
[2],
[3])
ANOTHER? y.
no
Note that this example comes from the categorial grammar in the
appendix. Also note that the feature structures are displayed in full
with tags indicating structure sharing. Next, note that prompts allow
the user to iterate through all the clauses. The number of solutions
might not correspond to the number of clause definitions in the
program due to disjunctions in descriptions which are resolved
non-deterministically when displaying rules. But it is important to
keep in mind that this feature structure notation for rules is not the
one ALE uses internally, which compiles rules down into
elementary operations which are then compiled, rather than evaluating
them as feature structures by unification. In this way, ALE is
more like a logic programming compiler than an interpreter. Finally,
note that the arity of the predicate being listed may be represented
in the query as in Prolog. For instance, the query show_clause
append/3 would show the clauses for append with three
arguments.
Definite clauses in ALE can be evaluated by using a query such
as:
[Code]
| ?- query append(X,Y,[a,b]).
append(e_list,
[0] ne_list
HD a
TL ne_list
HD b
TL e_list,
[0] )
ANOTHER? y.
append(ne_list
HD [0] a
TL e_list,
[1] ne_list
HD b
TL e_list,
ne_list
HD [0]
TL [1] )
ANOTHER? y.
append(ne_list
HD [0] a
TL ne_list
HD [1] b
TL e_list,
[2] e_list,
ne_list
HD [0]
TL ne_list
HD [1]
TL [2] )
ANOTHER? y.
no
The definition of append/3 is taken from the syllabification
grammar in the appendix. After displaying the first solution,
ALE queries the user as to whether or not to display another
solution. In this case, there are only three solutions, so the third
query for another solution fails. Note that the answers are given in
feature structure notation, where the macro [a,b] is converted to a
head/tail feature structure encoding.
Unlike Prolog, in which a solution is displayed as a substitution for the variables in the query, ALE displays a solution as a satisfier of the entire query. The reason for this is that structures which are not given as variables may also be further instantiated due to the type system. Definite clause resolution in ALE is such that only the most general solutions to queries are displayed. For instance, consider the following query, also from the syllabification grammar in the appendix:
| ?- query less_sonorous(X,r).
less_sonorous(nasal,
r)
ANOTHER? y.
less_sonorous(sibilant,
r)
ANOTHER? n.
Rather than enumerating all of the nasal and sibilant
types, ALE simply displays their supertype. On the other hand,
it is important to note that the query less_sonorous(s,r) would
succeed because s is a subtype of sibilant. This example
also clearly illustrates how ALE begins each argument on its own
line arranged with the query.
In general, the goal to be solved must be a literal, consisting only of a relation applied to arguments. In particular, it is not allowed to contain conjunction, disjunction, cuts, or other definite clause control structures. To solve a more complex goal, a definite clause must be defined with the complex goal as a body and then the head literal solved, which will involve the resolution of the body.
There are no routines to trace the execution of definite clauses. Future releases of ALE will contain a box port tracer similar to that used for Prolog. At present, the best suggestion is to develop definite clauses modularly and test them from the bottom-up to make sure they work before trying to incorporate them into larger programs.