Based on the project Jason by Jomi F. Hübner and Rafael H. Bordini a Java 9 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

Requirements

JRE 1.9

Development

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-annotations 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