To implement a working prototype, the proper Prolag code must be supplied for any agent in the system. This code must
The ability of automatically translating the agents' specifications into Prolag code and of reusing already implemented structures, should avoid the burden of a hand-made prototype implementation developed by scratch. The research in this direction is quite recent and far from resulting into a completely automatic translation process, but some preliminary, promising results have already been obtained.
In [3] an engine for the PRS architecture [8]
have been specified using 
. An approach to the translation of
rules into Prolag code has also been given.
The clauses used for specifying the PRS engine
assume the general form
where all the formulas 
are atomic. In
order to translate in Prolag a multi-conclusion guarded clause C of such a
form, it is necessary to introduce an auxiliary predicate 
, defined as
:- retract_state( 
),..., retract_state( 
),
,
assert_state( 
), ...,assert_state( 
).
where retract_state and assert_state are the predicates for
state update described in Subsection 5.1.
The execution of
retract_state( ),..., retract_state( ) consumes
the atomic formulas 
, the proof of 
tests both the clause guard and the condition over the current state, and
finally the execution of
assert_state( ), ..., assert_state( ) adds new
information to the state.
Applying this transformation to every clause, a corresponding set of
Prolag clauses is obtained. Such a set can be partitioned by
grouping together clauses regarding the four main activities performed by a
PRS agent that are perception, plan_triggering,
plan_execution
and action_execution.
The engine of a Prolag agent is defined by a predicate cycle.
The cycle defining the PRS engine results into:
cycle :- perception; plan_triggering; plan_execution; action_execution.
Each activity can be defined
by the clauses belonging to the corresponding activity group, for example
plan_triggering :- 
; ... ; 
where 
are the clauses of the plan
triggering group.
Another issue that have been considered is the compilation from ACLPL into
Prolag.
Due to their rule-based nature, ACLPL specifications can be easily translated
into a form that can be manipulated by a reactive-proactive engine.
A working compiler has been implemented, which takes as input an ACLPL\
program and generates a code of this form.
reactive_rule(Message, Condition, Actions).
...
proactive_rule(Condition, Actions).
...
p1(..) :- ...
...
pm(..) :- ...
reactive_rule is a reactive rule,
proctive_rule is a proactive rule and p1, ..., pm are
Prolag predicates.
The cycle for a reactive-proactive agent may have the form
cycle :-
async_receive_one(Msg_input, Msg_output),
(Msg_output == no_message ->
Actions1 = []
;
select_reactive_rule(Msg_output, Actions1)
),
select_proactive_rule(Actions2),
choose(Actions1, Actions2, Actions),
execute(Actions).
The predicate cycle defines a simple engine for the agent
architecture. First, the mail-box is inspected and a message is picked up
from it. Then, a fired reactive rule is selected from the agent behavior and the
set of associated actions is returned. Selection among proactive rules is also
performed, and a set of proactive actions is returned. Finally, a set of actions
is chosen and executed.
Obviously, more sophisticated strategies for rules selection and
actions choice can be taken into a more complete engine. The integration in
CaseLP of the
compiler for ACLPL and the engines for reactive, proactive and
reactive-proactive architecture has still to be completed.