| ?- 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. noNote 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. noThe 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.