LightJason - AgentSpeak(L++)
Based on the project Jason by Jomi F. Hübner and Rafael H. Bordini an implementation has been build-up with parallel execution calls. The version defines an additional AgentSpeak(L) grammar based on AntLR for simulating a multi-agent system with a fuzzy-based logical calculus and grammar features like lambda expressions. Agent execution based on a mathematical structure to describe an optimizing process by a finite-state-machine
Base Definitions
Belief
- Beliefs implicitly describe the current state of the agent
- Beliefs will be updated before the cycle is run (beliefbase uses an update mechanism)
- Beliefs must be exists iif an expression is computed (beliefs can be exist on the fly)
- Belief addition triggers a plan with the definition
+belief
- Belief retraction triggers a plan with the definition
-belief
- Belief modification with
-+
does not exists anymore
- Variables within a belief literal will be unified before the belief is added to the beliefbase
Action
- Actions will be run immediately
- Actions can fail (fuzzy-logic false) or succeed (fuzzy-logic true)
- There is no difference between internal and external actions
- Actions with
@
-prefix wil be executed in parallel (each inner action will be run in parallel)
Plan
- Plans are sequences of actions, rules and/or achievement / test goals
- Plans has got an optional context, that defines a constraint for execution (default is fuzzy-logic true and matches always)
- Plans fail iif the defuzzyfication returns fuzzy-logic false
- Plans returns a boolean value which defines fail (fuzzy-logic false) and success (fuzzy-logic true)
- Plans run items in sequential order on default
- If the plan calls an achievement goal addition, the goal will be added for the next cycle
- An achievement goal deletion does not exists anymore
Internals Constants
- The plan has got additional constant variables, that are added in the context condition (values are calculated before plan execution is started)
- PlanFail stores the number of fail runs and PlanFailRatio normalized value in [0,1]
- PlanSuccessful stores the number of successful runs and PlanSuccessfulRatio normalized value in [0,1]
- PlanRuns number of runs of the plan (fail + successful runs)
Fuzziness
- Fuzzy value must be in [0,1]
- Each action in a fuzzy-plan returns also a fuzzy value to define the fuzziness
- The plan or rule result returns fuzzy-logic true / false and the aggregated fuzzy value
Rule
- Rules are similar to plans without the context condition
- Rules cannot be triggered by a goal, so they must be called from a plan
- Rules will be executed with the prefix
$
- Rules run immediatly
- Rules run sequentially on default
- Rules returns a fuzzy-logic result for success or fail
- Variables will be passed, so if a rules succeed the value of the variable will be passed back to the calling plan
Rule / Plan Annotation
- Annotations can modify a plan / rule behaviour to change runtime semantic
- The following annotation can be used
@Constant( AnyValue, 5 )
creates the given constant variable
@Atomic
the plan / rule cannot be fail, it returns always true (only the actions can fail)
@Parallel
all items will be run in parallel
Goal
- Semantically a goal marks a certain state of the world an agent wishes to bring about [AgentSpeak, p.40]
- Achievement goals triggers an achievement goal addition which leads to the execution of a corresponding plan
- On agent start, there can exists one initial goal only (like the
main
function in Java or C/C++)
- Each agent can track more than one goal at the same time otherwise the agent idles (the suspending state is not used)
- Goals are triggered by external events which will match by the goal name
- Goals will be resolved into plans with equal name (and allowed context), the plan is the intantiiation of the goal
- Goals are run in parallel independed from other goals
- A goal is a sequence of plans which must all finished completly
- A goal is part of exactly one intention
- If a goal can match a desire (the goal is near to the desire) it can add an event to match the desire belief
- If the agent is in sleeping / hibernate state and the
wakeup
method is called, it triggers the wakeup-goal
Test Goals
- A test goal is an atom with the definition
?literal
- The test return true iif a plan with an equal literal is within the current execution context (current running)
Intention
- An intention is the convex hull of its goals
- The intention is set of of goals, which must exist simultaneously
- Intentions cannot be in conflict with other intentions, so there dies not exists any overlaping
Desire
- A Desire is a vertex of the edge of all intentions
- Desires are defined by a set of beliefs
- Desires can be in conflict with other desires, represented that the desires have got a large distance (much as possible)
- The desire is successfully reached, iif all beliefs are existing anytime
Variable
- Variables are written with an upper-case letter at begin
- Thread-safe variables for parallel runtime start with
@
(at-sign) followed by an upper-case letter
- Variables can store a literal or string to call a rule or plan e.g.
!X(3,2)
calls a plan or $X(2,1)
calls a rule
Action / Term Annotation
- In LightJason one can specify HOW actions and terms will be executed / unified.
- Concept of
action-term-annotation
s allows to annotate actions
, and terms
to perform
- unification (
>>
)
- parallel execution (
@
), see Variables and lambda expressions.
- ...
- If more than one
action-term-annotation
is needs to be added, they have to be ordered according to the rule: First HOW, then WHAT, e.g. @>>
(parallel unification)
- To annotate multiple actions/terms brackets
(
,)
can be used. See the following examples
- Examples
@>>( foo(X), X > 1 ) && Value > 0.5
(unify foo(X)
and X > 1
in parallel and if this results in a true statement check whether Value > 0.5
)
>>foo(X) && X > 1 && Value > 0.5
(unify foo(X)
, then test the following terms sequentially)
Graphical Representation