Stargazer allows you to write your own π-calculus program using the syntax documented on this page.

At the core of π-calculus there is the notion of name, often also called channel. Any identifier starting with lowercase is treaded as a channel name. Stargazer understands a definitional variant of π-calculus, which means that processes are defined by means of definitions. Any capitalised identifier is treated as a process identifier, to which a program will associate a unique definition. A definition for a process identifier D with n parameters will have the form D[y1,...,yn] := M where y1, ..., yn are the formal parameters and M is a guarded choice, that is a sum of actions α1.P1 + … + αn.Pn. There are three types of actions α.P:

• Output: x<y1,...,yn>.P
• Input: x(y1,...,yn).P
• Internal: tau.P

In each case P is the continuation of the action, i.e. what happens when the action is executed. When the continuation is the inactive process 0 (or zero) the action α.0 can be abbreviated with α. Addition + represents a (non-deterministic) choice between the available actions. So for example, a valid definition is

D[x,y,z] := x(w).D[w,y,z] + y<> + tau.(D[x,x,z] | D[y,x,z])

Your program should have the form

INIT
DEFS

Where INIT is a process and DEFS is a sequence of definitions.

Processes P can be any of the following:

• The inactive process: 0 or zero
  This is the process that does nothing (it is always omitted in the communication topology)

• Parallel: P | Q
  Represents two processes P and Q running in parallel; they may interact by performing dual actions on some common channel.

• Process call: P[y1,...,yn]
  It intuitively stands for its definition.

• Restriction: new y1,...,yn.P
  Intuitively it creates new channels with the corresponding names.

Parentheses can be used to group actions and delimit restrictions, for example: x(y).x(z) + x<a> is different from x(y).(x(z) + x<a>); and new x.(Q[x] | P[x]) is different from new x.Q[x] | P[x] (where the second x will be interpreted as a global free name).

Stargazer accepts normalised programs: the initial term should not contain choices and only the top-level of each definition should be a choice. For example:

new x,y.(A[x] | B[x,y])
A[x] := x(u).new z.(A[u] | B[u,x] | C[z,u])
B[x,y] := x<y>

is normalised, but

new x,y.(A[x] | x<y>)
A[x] := new z.x(u).(A[u] | u<x>| C[z,u])

is not since the initial term contains a choice x<y>, and so does the continuation in the definition of A[x]. Moreover the definition of A[x] contains a restriction at top level which is not allowed: if you need it there, move it outside in the call of A[x], otherwise consider if you meant to use it under a prefix.

Process calls A[x] where A is not defined, will be treated as if the definition was A[x] := 0.

Another important restriction: the free names of the body of a definition have to be bound by the definition's head! This means that the definition A[x] := x(y).(z<y> | A[y]) is not valid because z occurs free in the body but is not in the argument list. To fix the definition you have to include it as in A[x,z] := x(y).(z<y> | A[y,z]).

Names that are not bound by restrictions in the initial term are considered global names. The may or may not be included in the graphical representation of the communication topology depending on the setting "View globals" which can be toggled using the corresponding button in the toolbar.