Context Navigation

predicates.html

Visit:

Revision 4621, 43.3 KB (checked in by pmoura, 6 weeks ago)
Improved navigation bar in the XHTML manual pages.
Property svn:eol-style set to `native` Property svn:keywords set to `Author Date Id Revision`

Line
1	<?xml version="1.0" encoding="utf-8"?>
2	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
3	"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
4
5	<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
6
7	<head>
8	<meta http-equiv="content-type" content="application/xml+xhtml; charset=utf-8" />
9	<title>Logtalk user manual: predicates</title>
10	<link rel="stylesheet" href="../screen.css" type="text/css" media="screen"/>
11	<link rel="stylesheet" href="../print.css" type="text/css" media="print"/>
12	</head>
13
14	<body>
15
16	<div class="top-left">Logtalk user manual</div>
17	<div class="top-right">Predicates</div>
18	<div class="bottom-left"><span class="page"/></div>
19	<div class="bottom-right"><span class="page"/></div>
20	<div class="navtop"><a href="../index.html">Contents</a> > <a href="index.html">User Manual</a> > Predicates</div>
21
22	<h1 id="predicates_predicates">Predicates</h1>
23
24	<p>
25	Predicate directives and clauses can be encapsulated inside objects and categories. Protocols can only contain predicate directives. From the point-of-view of an object-oriented language, predicates allows both object state and object behavior to be represented. Mutable object state can be represented using dynamic object predicates.
26	</p>
27
28	<h2 id="predicates_declaring">Declaring predicates</h2>
29
30	<p>
31	All object (or category) predicates that we want to access from other objects must be explicitly declared. A predicate declaration must contain, at least, a scope directive. Other directives may be used to document the predicate or to ensure proper compilation of the predicate definitions.
32	</p>
33	<p>
34	Predicate directives should always precede the corresponding predicate definitions and/or calls in the source files in order to ensure proper compilation.
35	</p>
36
37	<h3 id="predicates_scope">Scope directives</h3>
38
39	<p>
40	A predicate can be <em>public</em>, <em>protected</em>, <em>private</em>, or <em>local</em>. Public predicates can be called from any object. Protected predicates can only be called from the container object or from a container descendant. Private predicates can only be called from the container object. Local predicates, like private predicates, can only be called from the container object (or category) but they are <em>invisible</em> to the reflection built-in methods (<code>current_predicate/1</code> and <code>predicate_property/2</code>) and to the message error handling mechanisms (i.e. sending a message corresponding to a local predicate results in a <code>predicate_declaration</code> existence error, not in a scope error).
41	</p>
42	<p>
43	The scope declarations are made using the directives <a title="Consult reference manual" href="../refman/directives/public1.html"><code>public/1</code></a>, <a title="Consult reference manual" href="../refman/directives/protected1.html"><code>protected/1</code></a>, and <a title="Consult reference manual" href="../refman/directives/private1.html"><code>private/1</code></a>. For example:
44	</p>
45	<pre>:- public(init/1).
46
47	:- protected(valid_init_option/1).
48
49	:- private(process_init_options/1).</pre>
50	<p>
51	If a predicate does not have a scope declaration, it is assumed that the predicate is local. Note that we do not need to write scope declarations for all defined predicates. One exception is local dynamic predicates: declaring them as private predicates may allow the Logtalk compiler to generate optimized code for asserting and retracting clauses.
52	</p>
53
54	<h3 id="predicates_mode">Mode directive</h3>
55
56	<p>
57	Many predicates cannot be called with arbitrary arguments with arbitrary instantiation status. The valid arguments and instantiation modes can be documented by using the <a title="Consult reference manual" href="../refman/directives/mode2.html"><code>mode/2</code></a> directive. For instance:
58	</p>
59	<pre>:- mode(member(?term, +list), zero_or_more).</pre>
60	<p>
61	The first argument describes a valid calling mode. The minimum information will be the instantiation mode of each argument. There are four possible values (described in <a title="ISO Prolog Standard" href="../bibliography.html#ISO95">[ISO 95]</a>):
62	</p>
63	<dl>
64	<dt><code>+</code></dt>
65	<dd>Argument must be instantiated.</dd>
66	<dt><code>-</code></dt>
67	<dd>Argument must be a free (non-instantiated) variable.</dd>
68	<dt><code>?</code></dt>
69	<dd>Argument can either be instantiated or free.</dd>
70	<dt><code>@</code></dt>
71	<dd>Argument will not be modified.</dd>
72	</dl>
73	<p>
74	These four mode atoms are also declared as prefix operators by the Logtalk compiler. This makes it possible to include type information for each argument like in the example above. Some of the possible type values are: <code>event</code>, <code>object</code>, <code>category</code>, <code>protocol</code>, <code>callable</code>, <code>term</code>, <code>nonvar</code>, <code>var</code>, <code>atomic</code>, <code>atom</code>, <code>number</code>, <code>integer</code>, <code>float</code>, <code>compound</code>, and <code>list</code>. The first four are Logtalk specific. The remaining are common Prolog types. We can also use our own types that can be either atoms or compound terms.
75	</p>
76	<p>
77	The second argument documents the number of proofs (or solutions) for the specified mode. The possible values are:
78	</p>
79	<dl>
80	<dt><code>zero</code></dt>
81	<dd>Predicate always fails.</dd>
82	<dt><code>one</code></dt>
83	<dd>Predicate always succeeds once.</dd>
84	<dt><code>zero_or_one</code></dt>
85	<dd>Predicate either fails or succeeds.</dd>
86	<dt><code>zero_or_more</code></dt>
87	<dd>Predicate has zero or more solutions.</dd>
88	<dt><code>one_or_more</code></dt>
89	<dd>Predicate has one or more solutions.</dd>
90	<dt><code>error</code></dt>
91	<dd>Predicate will throw an error (see below).</dd>
92	</dl>
93	<p>
94	Mode declarations can also be used to document that some call modes will throw an error. For instance, regarding the <code>arg/3</code> ISO Prolog built-in predicate, we may write:
95	</p>
96	<pre>:- mode(arg(-, -, +), error).</pre>
97	<p>
98	Note that most predicates have more than one valid mode implying several mode directives. For example, to document the possible use modes of the <code>atom_concat/3</code> ISO built-in predicate we would write:
99	</p>
100	<pre>:- mode(atom_concat(?atom, ?atom, +atom), one_or_more).
101	:- mode(atom_concat(+atom, +atom, -atom), zero_or_one).</pre>
102	<p>
103	Some old Prolog compilers supported some sort of mode directives to improve performance. To the best of my knowledge, there is no modern Prolog compiler supporting these kind of directive. The current version of the Logtalk compiler just parses and than discards this directive (however, see the description on <a title="Consult user manual" href="threads.html#threads_synchronized_predicates">synchronized predicates</a> on the <a title="Consult user manual" href="threads.html">multi-threading programming</a> section). Nevertheless, the use of mode directives is a good starting point for documenting your predicates.
104	</p>
105
106	<h3 id="predicates_meta">Meta-predicate directive</h3>
107
108	<p>
109	Some predicates may have arguments that will be called as goals or closures that will be used for constructing a call. To ensure that these calls and closures will be executed in the correct scope (i.e. in the calling context, <em>this</em>, not in the predicate definition context) we need to use the <a title="Consult reference manual" href="../refman/directives/meta_predicate1.html"><code>meta_predicate/1</code></a> directive. For example:
110	</p>
111	<pre>:- meta_predicate(findall(, ::, )).</pre>
112	<p>
113	The predicate arguments in this directive have the following meaning:
114	</p>
115	<dl>
116	<dt><code>::</code></dt>
117	<dd>Meta-argument that will be called as a goal.</dd>
118	<dt><code>N</code></dt>
119	<dd>Meta-argument that will be a closure used to construct a call by appending <code>N</code> arguments at the end. The value of <code>N</code> must be a positive integer.</dd>
120	<dt><code>*</code></dt>
121	<dd>Normal argument.</dd>
122	</dl>
123	<p>
124	This is similar to the declaration of meta-predicates in the ISO standard for Prolog modules except that we use the atom <code>::</code> instead of <code>:</code> to be consistent with the message sending operators. To the best of my knowledge, the use of non-negative integers to specify closures has first introduced on Quintus Prolog for providing information for predicate cross-reference tools.
125	</p>
126	<p>
127	The <code>meta_predicate/1</code> directive must precede the meta-predicate definition and any local calls to the meta-predicate in order to ensure proper compilation. In addition, as each Logtalk entity is independently compiled, this directive must be included in every object or category that contains a definition for the described predicate, even if the predicate declaration is inherited from another entity, to ensure proper compilation of meta-arguments.
128	</p>
129
130	<h3 id="predicates_discontiguous">Discontiguous directive</h3>
131
132	<p>
133	The clause of an object (or category) predicate may not be contiguous. In that case, we must declare the predicate discontiguous by using the <a title="Consult reference manual" href="../refman/directives/discontiguous1.html"><code>discontiguous/1</code></a> directive:
134	</p>
135	<pre>:- discontiguous(foo/1).</pre>
136	<p>
137	This is a directive that we should avoid using: it makes your code harder to read and it is not supported by some Prolog compilers.
138	</p>
139	<p>
140	As each Logtalk entity is compiled independently from other entities, this directive must be included in every object or category that contains a definition for the described predicate (even if the predicate declaration is inherited from other entity).
141	</p>
142
143	<h3 id="predicates_dynamic">Dynamic directive</h3>
144
145	<p>
146	An object predicate can be static or dynamic. By default, all object predicates are static. To declare a dynamic predicate we use the <a title="Consult reference manual" href="../refman/directives/dynamic1.html"><code>dynamic/1</code></a> directive:
147	</p>
148	<pre>:- dynamic(foo/1).</pre>
149	<p>
150	This directive may also be used to declare dynamic grammar rule non-terminals. As each Logtalk entity is compiled independently from other entities, this directive must be included in every object that contains a definition for the described predicate (even if the predicate declaration is inherited from other object or imported from a category). If we omit the dynamic declaration then the predicate definition will be compiled static. In the case of dynamic objects, static predicates cannot be redefined using the database built-in methods (despite being internally compiled to dynamic code).
151	</p>
152	<p>
153	Note that static objects may declare and define dynamic predicates.
154	</p>
155
156	<h3 id="predicates_op">Operator directive</h3>
157
158	<p>
159	An object (or category) predicate can be declared as an operator using the familiar <a title="Consult reference manual" href="../refman/directives/op3.html"><code>op/3</code></a> directive:
160	</p>
161	<pre>:- op(Priority, Specifier, Operator).</pre>
162	<p>
163	Operators are local to the object (or category) where they are declared. This means that, if you declare a public predicate as an operator, you cannot use operator notation when sending to an object (where the predicate is visible) the respective message (as this would imply visibility of the operator declaration in the context of the <em>sender</em> of the message). If you want to declare global operators and, at the same time, use them inside an entity, just write the corresponding directives at the top of your source file, before the entity opening directive.
164	</p>
165	<p>
166	When the same operators are used on several entities within the same source file, the corresponding directives must appear before any entity that uses them. However, this results in a global scope for the operators. If you prefer the operators to be local to the source file, just <em>undefine</em> them at the end of the file. For example:
167	</p>
168	<pre>:- op(400, xfx, results). % before any entity that uses the operator
169
170	...
171
172	:- op(0, xfx, results). % after all entities that used the operator</pre>
173
174	<h3 id="predicates_uses">Uses directive</h3>
175
176	<p>
177	When a predicate makes heavy use of predicates defined on other objects, its clauses can be excessively verbose due to all the necessary message sending constructs. Consider the following example:
178	</p>
179	<pre>foo :-
180	...,
181	findall(X, list::member(X, L), A),
182	list::append(A, B, C),
183	list::select(Y, C, R),
184	...</pre>
185	<p>
186	Logtalk provides a directive, <a title="Consult reference manual" href="../refman/directives/uses2.html"><code>uses/2</code></a>, which allows us to simplify the code above. The usage template for this directive is:
187	</p>
188	<pre>:- uses(Object, [Functor1/Arity1, Functor2/Arity2, ...]).</pre>
189	<p>
190	Rewriting the code above using this directive results in a simplified and more easily readable predicate definition:
191	</p>
192	<pre>:- uses(list,
193	[append/3, member/2, select/3]).
194
195	foo :-
196	...,
197	findall(X, member(X, L), A),
198	append(A, B, C),
199	select(Y, C, R),
200	...</pre>
201	<p>
202	Logtalk supports an extended version of this directive that allows the declaration of predicate alias using the notation <code>Predicate::Alias</code>. For example:
203	</p>
204	<pre>:- uses(btrees, [new/1::new_btree/1]).
205	:- uses(queues, [new/1::new_queue/1]).</pre>
206	<p>
207	You may use this extended version for solving conflicts between predicates declared on several <code>uses/2</code> directives or just for giving new names to the predicates that will be more meaningful on their using context.
208	</p>
209	<p>
210	The <code>uses/2</code> directive allows simpler predicate definitions as long as there are no conflicts between the predicates declared in the directive and the predicates defined in the object (or category) containing the directive. A predicate (or its alias if defined) cannot be listed in more than one <code>uses/2</code> directive. In addition, a <code>uses/2</code> directive cannot list a predicate (or its alias if defined) which is defined in the object (or category) containing the directive. Any conflicts are reported by the Logtalk pre-processor as compilation errors.
211	</p>
212	<p>
213	In the current Logtalk version, the omission of the <code>Object::</code> prefix is not supported when the predicate call occurs as an argument of a user-defined meta-predicate (Logtalk specified meta-predicates and Prolog non-standard meta-predicates declared in the config files pose no problem).
214	</p>
215
216	<h3 id="predicates_alias">Alias directive</h3>
217
218	<p>
219	Logtalk allows the definition of an alternative name for an inherited or imported predicate (or for an inherited or imported grammar rule non-terminal) through the use of the <a title="Consult reference manual" href="../refman/directives/alias3.html"><code>alias/3</code></a> directive:
220	</p>
221	<pre>:- alias(Entity, Predicate, Alias).</pre>
222	<p>
223	This directive can be used in objects, protocols, or categories. The first argument, <code>Entity</code>, must be an entity referenced in the opening directive of the entity contain the <code>alias/3</code> directive. It can be an implemented protocol, an imported category, an extended prototype, an instantiated class, or a specialized class. The second and third arguments are predicate indicators (or grammar rule non-terminal indicators).
224	</p>
225	<p>
226	A common use for the <code>alias/3</code> directive is to give an alternative name to an inherited predicate in order to improve readability. For example:
227	</p>
228	<pre>:- object(square,
229	extends(rectangle)).
230
231	:- alias(rectangle, width/1, side/1).
232
233	...
234
235	:- end_object.</pre>
236	<p>
237	The directive allows both <code>width/1</code> and <code>side/1</code> to be used as messages to the object <code>square</code>. Thus, using this directive, there is no need to explicitly declare and define a "new" <code>side/1</code> predicate. Note that the <code>alias/3</code> directive does not rename a predicate, only provides an alternative, additional name; the original name continues to be available.
238	</p>
239	<p>
240	Another common use for this directive is to solve conflicts when two inherited predicates have the same functor and arity. We may want to call the predicate which is masked out by the Logtalk lookup algorithm (see the <a href="inheritance.html">Inheritance</a> section) or we may need to call both predicates. This is simply accomplished by using the <code>alias/3</code> directive to give alternative names to masked out or conflicting predicates. Consider the following example:
241	</p>
242	<pre>:- object(my_data_structure,
243	extends(list, set)).
244
245	:- alias(list, member/2, list_member/2).
246	:- alias(set, member/2, set_member/2).
247
248	...
249
250	:- end_object.</pre>
251	<p>
252	Assuming that both <code>list</code> and <code>set</code> objects define a <code>member/2</code> predicate, without the <code>alias/3</code> directives, only the definition of <code>member/2</code> predicate in the object <code>list</code> would be visible on the object <code>my_data_structure</code>, as a result of the application of the Logtalk predicate lookup algorithm. By using the <code>alias/3</code> directives, all the following messages would be valid (assuming a public scope for the predicates):
253	</p>
254	<pre>\| ?- my_data_structure::list_member(X, L). % uses list member/2
255
256	\| ?- my_data_structure::set_member(X, L). % uses set member/2
257
258	\| ?- my_data_structure::member(X, L). % uses list member/2</pre>
259	<p>
260	When used this way, the <code>alias/3</code> directive provides functionality similar to programming constructs of other object-oriented languages which support multi-inheritance (the most notable example probably being the renaming of inherited features in Eiffel).
261	</p>
262	<p>
263	Note that the <code>alias/3</code> directive never hides a predicate which is visible on the entity containing the directive as a result of the Logtalk lookup algorithm. However, it may be used to make visible a predicate which otherwise would be masked by another predicate, as illustrated in the above example.
264	</p>
265	<p>
266	The <code>alias/3</code> directive may also be used to give access to an inherited predicate, which otherwise would be masked by another inherited predicate, while keeping the original name as follows:
267	</p>
268	<pre>:- object(my_data_structure,
269	extends(list, set)).
270
271	:- alias(list, member/2, list_member/2).
272	:- alias(set, member/2, set_member/2).
273
274	member(X, L) :-
275	::set_member(X, L).
276
277	...
278
279	:- end_object.</pre>
280	<p>
281	Thus, when sending the message <code>member/2</code> to <code>my_data_structure</code>, the predicate definition in <code>set</code> will be used instead of the one contained in <code>list</code>.
282	</p>
283
284	<h3 id="predicates_info">Documenting directive</h3>
285
286	<p>
287	A predicate can be documented with arbitrary user-defined information by using the <a title="Consult reference manual" href="../refman/directives/info2.html"><code>info/2</code></a> directive:
288	</p>
289	<pre>:- info(Functor/Arity, List).</pre>
290	<p>
291	The second argument is a list of <code>Key is Value</code> terms. See the <a href="documenting.html">Documenting Logtalk programs</a> session for details.
292	</p>
293
294	<h2 id="predicates_defining">Defining predicates</h2>
295
296	<h3 id="predicates_objects">Object predicates</h3>
297
298	<p>
299	We define object predicates as we have always defined Prolog predicates, the only difference be that we have four more control structures (the three message sending operators plus the external call operator) to play with. For example, if we wish to define an object containing common utility list predicates like <code>append/2</code> or <code>member/2</code> we could write something like:
300	</p>
301	<pre>:- object(list).
302
303	:- public(append/3).
304	:- public(member/2).
305
306	append([], L, L).
307	append([H\| T], L, [H\| T2]) :-
308	append(T, L, T2).
309
310	member(H, [H\| _]).
311	member(H, [_\| T]) :-
312	member(H, T).
313
314	:- end_object.</pre>
315	<p>
316	Note that, abstracting from the opening and closing object directives and the scope directives, what we have written is plain Prolog. Calls in a predicate definition body default to the local predicates, unless we use the message sending operators or the external call operator. This enables easy conversion from Prolog code to Logtalk objects: we just need to add the necessary encapsulation and scope directives to the old code.
317	</p>
318
319	<h3 id="predicates_categories">Category predicates</h3>
320
321	<p>
322	Because a category can be imported by several different objects, dynamic private predicates must be called using the <a title="Consult reference manual" href="../refman/control/to_self1.html"><code>::/1</code></a> message sending operator. This ensures that the correct predicate definition will be used. For example, if we want to define a category implementing variables using destructive assignment we could write:
323	</p>
324	<pre>:- category(variable).
325
326	:- public(get/2).
327	:- public(set/2).
328
329	:- private(value_/2).
330	:- dynamic(value_/2).
331
332	get(Var, Value) :-
333	::value_(Var, Value).
334
335	set(Var, Value) :-
336	::retractall(value_(Var, _)),
337	::asserta(value_(Var, Value).
338
339	:- end_category.</pre>
340	<p>
341	This way, each importing object will have its own definition for the <code>value_/2</code> private predicate. Furthermore, the <code>get/2</code> and <code>set/2</code> predicates will always access/update the correct definition, contained in the object receiving the messages.
342	</p>
343	<p>
344	A category may only contain clauses for static predicates. Nevertheless, as the example above illustrates, there are no restrictions in declaring and calling dynamic predicates from inside a category.
345	</p>
346
347	<h3 id="predicates_metadef">Meta-predicates</h3>
348
349	<p>
350	Meta-predicates may be defined inside objects (and categories) as any other predicate. A meta-predicate is declared using the <code>meta_predicate/1</code> directive as described earlier on this section. When defining a meta-predicate, the arguments in the clause heads corresponding to the meta-arguments must be variables. All meta-arguments are called in the context of the object calling the meta-predicate (either directly or through message sending).
351	</p>
352	<p>
353	Some meta-predicates have meta-arguments which are not goals but closures. Logtalk supports the definition of meta-predicates that are called with closures instead of goals as long as the definition uses the Logtalk built-in predicate <a title="Consult reference manual" href="../refman/methods/call1.html"><code>call/N</code></a> to call the closure with the addtional arguments. For example:
354	</p>
355	<pre>:- public(all_true/2).
356	:- meta_predicate(all_true(1, *)).
357
358	all_true(_, []).
359	all_true(Closure, [Arg\| Args]) :-
360	call(Closure, Arg),
361	all_true(Closure, Args).</pre>
362	<p>
363	Note that the meta-predicate directive specifies that the closure will be extended with exactly one extra argument.
364	</p>
365
366	<h3 id="predicates_dcgs">Definite clause grammars</h3>
367
368	<p>
369	Definite clause grammar rules provide a convenient notation to represent the rewrite rules common of most grammars in Prolog. In Logtalk, definite clause grammar rules can be encapsulated in objects and categories. Currently, the ISO/IEC WG17 group is working on a draft specification for a definite clause grammars Prolog standard. Therefore, in the mean time, Logtalk follows the common practice of Prolog compilers supporting definite clause grammars, extending it to support calling grammar rules contained in categories and objects. A common example of a definite clause grammar is the definition of a set of rules for parsing simple arithmetic expressions:
370	</p>
371	<pre>:- object(calculator).
372
373	:- public(parse/2).
374
375	parse(Expression, Value) :-
376	phrase(expr(Value), Expression).
377
378	expr(Z) --> term(X), "+", expr(Y), {Z is X + Y}.
379	expr(Z) --> term(X), "-", expr(Y), {Z is X - Y}.
380	expr(X) --> term(X).
381
382	term(Z) --> number(X), "", term(Y), {Z is X Y}.
383	term(Z) --> number(X), "/", term(Y), {Z is X / Y}.
384	term(Z) --> number(Z).
385
386	number(C) --> "+", number(C).
387	number(C) --> "-", number(X), {C is -X}.
388	number(X) --> [C], {0'0 =< C, C =< 0'9, X is C - 0'0}.
389
390	:- end_object. </pre>
391	<p>
392	The predicate <a title="Consult reference manual" href="../refman/methods/phrase2.html"><code>phrase/2</code></a> called in the definition of predicate <code>parse/2</code> above is a Logtalk built-in method, similar to the predicate with the same name found on most Prolog compilers that support definite clause grammars. After compiling and loading this object, we can test the grammar rules with calls such as the following one:
393	</p>
394	<pre>\| ?- calculator::parse("1+2-3*4", Result).
395
396	Result = -9
397	yes</pre>
398	<p>
399	In most cases, the predicates resulting from the translation of the grammar rules to regular clauses are not declared. Instead, these predicates are usually called by using the built-in methods <code>phrase/2</code> and <code>phrase/3</code> as shown in the example above. When we want to send the messages <code>phrase/2</code> and <code>phrase/3</code> to <em>self</em> or to another object, the non-terminal used as first argument must be within the scope of the <em>sender</em>. For the above example, assuming that we want the predicate corresponding to the <code>expr//1</code> non-terminal to be public, the corresponding scope directive would be:
400	</p>
401	<pre>:- public(expr//1). </pre>
402	<p>
403	The <code>//</code> infix operator used above tells the Logtalk compiler that the scope directive refers to a grammar rule non-terminal, not to a predicate. The idea is that the predicate corresponding to the translation of the <code>expr//1</code> non-terminal will have a number of arguments equal to one plus the number of additional arguments necessary for processing the subjacent lists of tokens.
404	</p>
405	<p>
406	In the body of a grammar rule, we can call rules that are inherited from ancestor objects, imported from categories, or contained in other objects. This is accomplished by using non-terminals as messages. Using a non-terminal as a message to <em>self</em> allows us to call grammar rules in categories and ancestor objects. To call grammar rules encapsulated in other objects, we use a non-terminal as a message to those objects. Consider the following example, containing grammar rules for parsing natural language sentences:
407	</p>
408	<pre>:- object(sentence,
409	imports(determiners, nouns, verbs)).
410
411	:- public(parse/2).
412
413	parse(List, true) :-
414	phrase(sentence, List).
415	parse(_, false).
416
417	sentence --> noun_phrase, verb_phrase.
418
419	noun_phrase --> ::determiner, ::noun.
420	noun_phrase --> ::noun.
421
422	verb_phrase --> ::verb.
423	verb_phrase --> ::verb, noun_phrase.
424
425	:- end_object.</pre>
426	<p>
427	The categories imported by the object would contain the necessary grammar rules for parsing determiners, nouns, and verbs. For example:
428	</p>
429	<pre>:- category(determiners).
430
431	:- private(determiner//0).
432
433	determiner --> [the].
434	determiner --> [a].
435
436	:- end_category.</pre>
437	<p>
438	Along with the message sending operators (<code>::/1</code> and <code>::/2</code>), we may also use other control constructs such as <code>\+/1</code>, <code>!/0</code>, <code>;/2</code>, <code>->/2</code>, and <code>{}/1</code> in the body of a grammar. In addition, grammar rules may contain meta-calls (a variable taking the place of a non-terminal), which are translated to calls of the built-in method <code>phrase/3</code>.
439	</p>
440	<p>
441	You may have noticed that Logtalk defines <code>{}/1</code> as a control construct for bypassing the compiler when compiling a clause body goal. As exemplified above, this is the same control construct that is used in grammar rules for bypassing the expansion of rule body goals when a rule is converted into a clause. Both control constructs can be combined in order to call a goal from a grammar rule body, while bypassing at the same time the Logtalk compiler. Consider the following example:
442	</p>
443	<pre>bar :-
444	write('bar predicate called'), nl.
445
446
447	:- object(bypass).
448
449	:- public(foo//0).
450
451	foo --> {{bar}}.
452
453	:- end_object.</pre>
454	<p>
455	After compiling and loading this code, we may try the following query:
456	</p>
457	<pre>\| ?- bypass::phrase(foo, _, _).
458
459	bar predicate called
460	yes</pre>
461	<p>
462	This is the expected result as the expansion of the grammar rule into a clause leaves the <code>{bar}</code> goal untouched, which, in turn, is converted into the goal <code>bar</code> when the clause is compiled.
463	</p>
464	<p>
465	A grammar rule non-terminal may be declared as dynamic or discontiguous, as any object predicate, using the same <code><em>Functor//Arity</em></code> notation illustrated above for the scope directives. In addition, grammar rule non-terminals can be documented using the <a title="Consult reference manual" href="../refman/directives/info2.html"><code>info/2</code></a> directive, as in the following example:
466	</p>
467	<pre>:- public(sentence//0).
468
469	:- info(sentence//0, [
470	comment is 'Rewrites a sentence into a noun phrase and a verb phrase.']).</pre>
471
472	<h2 id="predicates_methods">Built-in object predicates (methods)</h2>
473
474	<p>
475	Logtalk defines a set of built-in object predicates or methods to access message execution context, to find sets of solutions, to inspect objects and for database handling. Similar to Prolog built-in predicates, these built-in methods should not be redefined.
476	</p>
477
478	<h3 id="predicates_context">Execution context methods</h3>
479
480	<p>
481	Logtalk defines four built-in methods to access an object execution context. These methods (with the possible exception of <code>parameter/2</code>) are translated to a single unification performed at compile time with a clause head context argument. Therefore, they can be freely used without worrying about performance penalties. When called from inside a category, these methods refer to the execution context of the object importing the category.
482	</p>
483	<p>
484	To find the object that received the message under execution we may use the <a title="Consult reference manual" href="../refman/methods/self1.html"><code>self/1</code></a> method. We may also retrieve the object that has sent the message under execution using the <a title="Consult reference manual" href="../refman/methods/sender1.html"><code>sender/1</code></a> method.
485	</p>
486	<p>
487	The method <a title="Consult reference manual" href="../refman/methods/this1.html"><code>this/1</code></a> enables us to retrieve the name of the object that contains the predicate clause that is being executed instead of using the name directly. This helps to avoid breaking the code if we decide to change the object name and forget to change the name references. This method may also be used from within a category. In this case, the method returns the object importing the category on whose behalf the predicate clause is being executed.
488	</p>
489	<p>
490	Here is a short example including calls to these three object execution context methods:
491	</p>
492	<pre>:- object(test).
493
494	:- public(test/0).
495
496	test :-
497	this(This),
498	write('Executing a predicate definition contained in '), writeq(This), nl,
499	self(Self),
500	write('to answer a message received by '), writeq(Self), nl,
501	sender(Sender),
502	write('that was sent by '), writeq(Sender), nl, nl.
503
504	:- end_object.
505
506
507	:- object(descendant,
508	extends(test)).
509
510	:- end_object.</pre>
511	<p>
512	After compiling and loading these two objects, we can try the following goal:
513	</p>
514	<pre>\| ?- descendant::test.
515
516	Executing a predicate definition contained in test
517	to answer a message received by descendant
518	that was sent by user
519	yes</pre>
520	<p>
521	Note that the goals <code>self(Self)</code>, <code>sender(Sender)</code>, and <code>this(This)</code>, being translated to unifications with the clause head context arguments at compile time, are effectively removed from the clause body. Therefore, a clause such as:
522	</p>
523	<pre>predicate(Arg) :-
524	self(Self),
525	atom(Arg),
526	... .</pre>
527	<p>
528	is compiled with the goal <code>atom(Arg)</code> as the first condition on the clause body. As such, the use of these context execution methods do not interfere with the optimizations that some Prolog compilers perform when the first clause body condition is a call to a built-in type-test predicate or a comparison operator.
529	</p>
530	<p>
531	For parametric objects, the method <a title="Consult reference manual" href="../refman/methods/parameter2.html"><code>parameter/2</code></a> enables us to retrieve current parameter values (see the session on <a href="objects.html#parametric">parametric objects</a> for a detailed description). For example:
532	</p>
533	<pre>:- object(block(_Color)).
534
535	:- public(test/0).
536
537	test :-
538	parameter(1, Color),
539	write('Color parameter value is '), writeq(Color), nl.
540
541	:- end_object.</pre>
542	<p>
543	After compiling and loading these two objects, we can try the following goal:
544	</p>
545	<pre>\| ?- block(blue)::test.
546
547	Color parameter value is blue
548	yes</pre>
549	<p>
550	The method <code>parameter/2</code> is only translated to a compile time unification when used inside objects with its first argument instantiated at compile time. When the first argument is not known at compile time, or when the method is used inside categories, its call results in a call to the built-in Prolog predicate <code>arg/3</code>. Nevertheless, note that calls to <code>parameter/2</code> from inside categories are inherently problematic: a category may be implemented by several objects, both parametric (with different number of parameters) and non-parametric. Care must be taken to ensure that a parametric object importing such a category match the interpretation of its parameters used in the category.
551	</p>
552
553	<h3 id="predicates_database">Database methods</h3>
554
555	<p>
556	Logtalk provides a set of built-in methods for object database handling similar to the usual database Prolog predicates: <a title="Consult reference manual" href="../refman/methods/abolish1.html"><code>abolish/1</code></a>, <a title="Consult reference manual" href="../refman/methods/asserta1.html"><code>asserta/1</code></a>, <a title="Consult reference manual" href="../refman/methods/assertz1.html"><code>assertz/1</code></a>, <a title="Consult reference manual" href="../refman/methods/clause2.html"><code>clause/2</code></a>, <a title="Consult reference manual" href="../refman/methods/retract1.html"><code>retract/1</code></a>, and <a title="Consult reference manual" href="../refman/methods/retractall1.html"><code>retractall/1</code></a>. These methods always operate on the database of the object receiving the corresponding message.
557	</p>
558	<p>
559	When working with dynamic grammar rule non-terminals, you may use the built-in method <a title="Consult reference manual" href="../refman/methods/expand_term2.html"><code>expand_term/2</code></a> convert a grammar rule into a clause that can than be used with the database methods.
560	</p>
561
562	<h3 id="predicates_metacalls">Meta-call methods</h3>
563
564	<p>
565	Logtalk supports the generalizaed <a title="Consult reference manual" href="../refman/methods/call1.html"><code>call/N</code></a> predicate as a built-in. This built-in predicate must be used in the implementation of meta-predicates which work with closures instead of goals.
566	</p>
567
568	<h3 id="predicates_solutions">All solutions methods</h3>
569
570	<p>
571	The usual all solutions meta-predicates are pre-defined methods in Logtalk: <a title="Consult reference manual" href="../refman/methods/bagof3.html"><code>bagof/3</code></a>, <a title="Consult reference manual" href="../refman/methods/findall3.html"><code>findall/3</code></a>, and <a title="Consult reference manual" href="../refman/methods/setof3.html"><code>setof/3</code></a>. There is also a <a title="Consult reference manual" href="../refman/methods/forall2.html"><code>forall/2</code></a> method that implements generate and test loops.
572	</p>
573
574	<h3 id="predicates_reflection">Reflection methods</h3>
575
576	<p>
577	Logtalk provides two built-in methods for inspecting object predicates: <a title="Consult reference manual" href="../refman/methods/predicate_property2.html"><code>predicate_property/2</code></a>, which returns predicate properties and <a title="Consult reference manual" href="../refman/methods/current_predicate1.html"><code>current_predicate/1</code></a>, which enables us to query about predicate definitions. See below for a more detailed description of both methods.
578	</p>
579
580	<h3 id="predicates_parsing">Definite clause grammar parsing methods</h3>
581
582	<p>
583	Logtalk supports two definite clause grammar parsing built-in methods, <a title="Consult reference manual" href="../refman/methods/phrase2.html"><code>phrase/2</code></a> and <a title="Consult reference manual" href="../refman/methods/phrase3.html"><code>phrase/3</code></a>, with definitions similar to the predicates with the same name found on most Prolog compilers that support definite clause grammars.
584	</p>
585
586	<h3 id="predicates_expanding">Term and goal expansion methods</h3>
587
588	<p>
589	Logtalk supports a <a title="Consult reference manual" href="../refman/methods/expand_term2.html"><code>expand_term/2</code></a> built-in method for expanding a term into a list of terms. This method is mostly used to translate grammar rules into Prolog clauses. It can be customized, e.g. for bypassing the default Logtalk grammar rule translator, by defining clause for the predicate <a title="Consult reference manual" href="../refman/methods/term_expansion2.html"><code>term_expansion/2</code></a>.
590	</p>
591	<p>
592	Logtalk supports a <a title="Consult reference manual" href="../refman/methods/expand_goal2.html"><code>expand_goal/2</code></a> built-in method for expanding a goal. This method can be customized by defining clause for the predicate <a title="Consult reference manual" href="../refman/methods/goal_expansion2.html"><code>goal_expansion/2</code></a>.
593	</p>
594
595	<h2 id="predicates_properties">Predicate properties</h2>
596
597	<p>
598	We can find the properties of visible predicates by calling the <a title="Consult reference manual" href="../refman/methods/predicate_property2.html"><code>predicate_property/2</code></a> built-in method. For example:
599	</p>
600	<pre>\| ?- bar::predicate_property(foo(_), Property).</pre>
601	<p>
602	Note that this method respects the predicate's scope declarations. For instance, the above call will only return properties for public predicates.
603	</p>
604	<p>
605	An object's set of visible predicates is the union of all the predicates declared for the object with all the built-in methods and all the Logtalk and Prolog built-in predicates.
606	</p>
607	<p>
608	Possible predicate properties values are:
609	</p>
610	<ul>
611	<li><code>public</code>, <code>protected</code>, <code>private</code></li>
612	<li><code>static</code>, <code>dynamic</code></li>
613	<li><code>built_in</code></li>
614	<li><code>meta_predicate(Mode)</code></li>
615	<li><code>declared_in(Entity)</code></li>
616	<li><code>defined_in(Entity)</code></li>
617	<li><code>non_terminal(NonTerminal//Arity)</code></li>
618	<li><code>alias_of(Predicate)</code></li>
619	<li><code>synchronized</code></li>
620	</ul>
621	<p>
622	The properties <code>declared_in/1</code> and <code>defined_in/1</code> do not apply to built-in methods and Logtalk or Prolog built-in predicates. Note that if a predicate is declared in a category imported by the object, it will be the category name — not the object name — that will be returned by the property <code>declared_in/1</code>. The same goes for protocol declared predicates.
623	</p>
624	<p>
625	The predicate property <code>defined_in(Entity)</code> results in the definitions for the predicate being looked up in <code>Entity</code>. This does not necessarily implies that clauses for the predicate exist in <code>Entity</code>; the predicate can simply be false (closed world assumption).
626	</p>
627	<p>
628	The property <code>non_terminal/1</code> only applies to predicates that result from the compilation of grammar rule non-terminals.
629	</p>
630	<p>
631	The property <code>alias_of/1</code> is returned for a predicate that is an alias of another predicate (which is returned in the property argument).
632	</p>
633	<p>
634	The property <code>synchronized</code> is returned for predicates that are declared synchronized when using multi-threading programming.
635	</p>
636
637
638	<h2 id="predicates_finding">Finding declared predicates</h2>
639
640	<p>
641	We can find, by backtracking, all visible user predicates by calling the <a title="Consult reference manual" href="../refman/methods/current_predicate1.html"><code>current_predicate/1</code></a> built-in method. This method respects the predicate's scope declarations. For instance, the following call:
642	</p>
643	<pre>\| ?- some_object::current_predicate(Functor/Arity).</pre>
644	<p>
645	will only return user predicates that are declared public. The predicate property <code>non_terminal/1</code> may be used to retrieve all grammar rule non-terminals declared for an object. For example:
646	</p>
647	<pre>current_non_terminal(Object, NonTerminal//Args) :-
648	Object::current_predicate(Functor/Arity),
649	functor(Predicate, Functor, Arity),
650	Object::predicate_property(Predicate, non_terminal(NonTerminal//Args)).</pre>
651	<p>
652	Usually, the non-terminal and the corresponding predicate share the same functor but users should not rely on this always being true.
653	</p>
654
655	<h2 id="predicates_prolog">Calling Prolog built-in predicates</h2>
656
657	<p>
658	In predicate definitions, predicate calls which are not prefixed with a message sending operator (either <code>::</code> or <code>^^</code>), are compiled to either calls to local predicates or as calls to Logtalk/Prolog built-in predicates. A predicate call is compiled as a call to a local predicate if the object (or category) contains a scope directive, a definition for the called predicate, or a dynamic declaration for it. When the object (or category) does not contain either a definition of the called predicate or a corresponding dynamic declaration, Logtalk tests if the call corresponds to a Logtalk or Prolog built-in predicate. Calling a predicate which is neither a local predicate nor a Logtalk/Prolog built-in predicate results in a compile time warning. This means that, in the following example:
659	</p>
660	<pre>foo :-
661	...,
662	write(bar),
663	...</pre>
664	<p>
665	the call to the predicate <code>write/1</code> will be compiled as a call to the corresponding Prolog built-in predicate unless the object (or category) encapsulating the above definition also contains a predicate named <code>write/1</code> or a dynamic declaration for the predicate.
666	</p>
667	<p>
668	When calling non-standard Prolog built-in predicates or using non-standard Prolog arithmetic functions, you may run into portability problems while trying your applications with different back-end Prolog compilers (non-standard predicates and non-standard arithmetic functions are often specific to a Prolog compiler). You may use the Logtalk compiler flag <a title="Consult user manual" href="programming.html#options"><code>portability/1</code></a> to help check for problematic calls in your code.
669	</p>
670
671	<h3 id="predicates_prolog_meta">Calling Prolog non-standard meta-predicates</h3>
672
673	<p>
674	Compiling calls to non-standard, Prolog built-in meta-predicates can be tricky for two reasons: first, there is no standard way of checking if a built-in predicate is also a meta-predicate and finding out which are its meta-arguments; second, in some cases, the meta-arguments of a meta-predicate are not goals but closures, used for constructing goals. The way the goals are constructed is specific to the meta-predicate and cannot be reliable inferred by the Logtalk compiler. For meta-predicates whose meta-arguments are directly called as goals, the solution is to explicitly declare them in the corresponding Prolog configuration file using the predicate <code>'$lgt_pl_meta-predicate'/1</code>. For example:
675	</p>
676	<pre>'$lgt_pl_meta_predicate'(call_with_depth_limit(::, , )).</pre>
677	<p>
678	Currently, there is no clean workaround for calling non-standard, Prolog built-in meta-predicates whose meta-arguments are used as closures instead of called as goals directly.
679	</p>
680
681	<div class="footer">
682	<div class="copyright">
683	<span>Copyright © <a href=