Each LCC interaction model is defined by a set of clauses where each clause has the syntax shown in Figure 3. Each clause is a self contained definition of a role, with message passing being the only means of transferring information between roles. Message passing is also the only means of synchronisation between roles.

  Clause := Role :: Def
    Role := a(Type, Id)
     Def := Role | Message | Def then Def | Def or Def
 Message := M ⇒ Role | M ⇒ Role ← C | M ⇐ Role | C ← M ⇐ Role
       C := Constant | P(T m, ...) | ¬C | C ∧ C | C ∨ C
    Type := Term
      Id := Constant | V ariable
       M := Term
    Term := Constant | Variable | P(Term, ...)
Constant := lower case character sequence or number
Variable := upper case character sequence or number

Figure 3. LCC Syntax

In the sections which follow we explain what each element of LCC syntax means from a programming point of view.

• Variables, Constants, Terms, IDs and Roles

Variables must start with an upper case letter. The scope of a variable is local to a clause (in other words, if you use the same variable name in different clauses then these names refer to different variables). When it is unnecessary to give a specific name for a variable (because it is not used elsewhere in a clause) you can use an underscore (_) for the variable name. Constants must start with a lower case letter. Numbers also are constants. Terms are tree-structured - that is, they are either a constant or are of the form F(A₁, ..., A_n) where F is a non-numerical constant and each A_i is a term. IDs are unique identifiers for peers which must be non-numerical constants. Roles are terms that describe the type of role played by a peer in a given interaction.

• Messages

There are two types of messages:
Incoming Messages : are of the form Term ⇐ a(Role,ID), where Term is the content of the message. When using ASCII, the symbol ⇐ is written using <=.
Outgoing Messages : are of the form Term ⇒ a(Role,ID), where Term is the content of the message. When using ASCII, the symbol ⇒ is written using =>.

Constraints can be attached to both incoming and outgoing messages (see below).

• Constraints

Constraints associate message passing events with conditions established by the peer.

Message ← constraint(Arg1, ..., ArgN)                             (1.3)

Constraints also may be associated with the special null event which represents an event that is not associated with a specific message. This frequently is used in recursive role definition where terminating the role depends on a parameter to the role, rather than a specific message passing event.

When using ASCII the constraint operator ← should be written using <-.

Visual Constraints
A constraint can have a mapping made available to it using the visual(,) operator. The visual operator maps a constraint to a visual term. Visual terms provide an abstract representation for a particular type of user interaction.

visual(constraint(Arg1, ..., ArgN), visualTerm(vArg1, ..., vArgN))         (1.4)

The OpenKnowledge kernel has a number of built-in visual term implementations, listed below:
msg(M⟨,T⟩) Display a message M to the user, with the optional title T.
text(⟨T,⟩M) Display a large amount of text in M to the user, with the optional title T.
input(⟨Q,⟩V) Ask the user to input some value into V, providing optional question text in Q.

List Operations
List operations are a common basis of the recursion techniques available when writing LCC. List operations make use of the bar | operation that delineates the head (H, first element) of a list from the rest of the list (T, the tail); that is, L = [H|T].

In the case that H has some value, you can append this value to the head of the list using the following constraint:

... ← L = [H|T]                                  (1.5)

For example, if before the operation H contained the value 5, and the list, L, contained [6,7,8], after the operation the list would contain the values [5,6,7,8].

In the case that H is not set, the following LCC will extract into H the value of the head of the list.

... ← L = [H|T]                                  (1.6)

Notice that T is itself a list, so that the head of T will be the second element in the list. This allows for recursion on T. If the list is empty, and no value for H can be determined, the constraint will fail. For example, if before the operation H was unset and the list, L, contained [6,7,8], after the operation H would have the value 6 and the T would have the value [7,8].

To test whether a list is empty, use the following LCC:

... ← L = []                                    (1.7)

This constraint will fail if L is not empty.

Logical Operators
Constraints can be connected by the logical operators and and or:

• C₁ and C₂ succeeds if both constraints C₁ and C₂ succeed, with C₁ being attempted first.
• C₁ and C₂ succeeds if one of the constraints C₁ and C₂ succeeds, with C₁ being attempted first.
• Comments

To comment your LCC you can use the C-like comments //... or /*...*/. The double-slash comment form will make the interpreter ignore the rest of the line. The slash-star comment form will ignore everything until the next star-slash. The following are valid comments:

// A valid single line comment
// Another single line comment

/* 
   A valid
   multi-line
   comment
*/

• Sequence and Choice

The basic operations used in LCC to determine the sequence of messages in a clause are sequence and choice, as defined below (where E₁ and E₂ are sequence expressions or message passing events):

Sequence : is written as E₁ then E₂. This sequence is completed if both E₁ or E₂ is completed, with E₁ being completed first.
Choice :is written as E₁ or E₂. This sequence is completed if either E₁ or E₂ is completed, with E₁ being attempted first. E₂ will only be attempted if E₁ fails. If E₁ succeeds then E₂ will not be attempted.