Translation Functions

In this section, we define a functionTprogJK:PC−→ PQ wherePC andPQ are the

set of CQP processes and QMC programs respectively. We follow a similar approach to Nielson and Nielson [1999]; the translation is defined in several steps on the struc- tural elements of CQP. We will introduce functions to translate processes in parallel contexts, expressions, types and values.

A QMC program consists of one or more named processes. Although the formal syntax of CQP does not feature named processes, we choose to use them as standard

T ::= Int | Unit | Qbit | _b[ ˜T] | Op(1) | Op(2) | . . . e ::= v | measure˜e | e˜∗=ee | e+e

v ::= x | 0 | 1 | · · · | unit | H | X | · · ·

P ::= 0 | (P rocN ame(˜x)kP rocN ame(˜x)) | e?[˜x: ˜T].P | e![˜e].P

| {e}.P | (νx:_b[T])P | (qbit x)P D ::= P rocN ame(˜x: ˜T) =P

C ::= D˜

Figure 6.4. CQP syntax with named processes.

(as, for example, the processes Teleport, Alice and Bob in Figure 6.10) instead of introducing arbitrary names as part of the translation. In this approach, the parallel composition primitive must use process names instead of processes. For example, the processP.(QkR) would be represented by the named processes

Process1 = P.(Process2 k Process3)

Process2 = Q

Process3 = R .

Formally, for this translation we define additional non-terminals, D for process definitions andCfor a collection of process definitions, to the CQP syntax in order to introduce named processes. Processes P are also modified such that parallel process constructs are written as calls to named processes. This extended grammar is shown in Figure 6.4.

These new syntactic elements do not change the language, however we must re- member that each named process may only appear once. We shall refer to the col- lection of process definitions as a CQPprogram, in order to distinguish between the collection and the individual processes.

We now define a series of transcription functions from the syntactic elements of CQP to the corresponding QMC syntax. These are: _TprogJK for the program; TprocJKfor processes;TexprJKfor expressions;TvalJKfor values; andTtypeJKfor

types.

The Program

The complete CQP program (C), which consists of the list of named processes (D1,

. . . , Dn), must be rewritten to a QMC program. This top-level transcription is performed using the function TprogJK, defined in Figure 6.5. The resulting QMC

TprogJC=D1, . . . , DnK=

program Translated;gVars(C);

TprogJD1K· · ·TprogJDnK

endprogram

TprogJProcName(ex:Te) =PK=

process ProcName;lVars(P)

begin isInvoked(ProcName) TprocJPK

end

Figure 6.5. Translation of programs.

followed by a list of process blocks. Each process block corresponds to a named CQP process, and these are translated in turn using_TprogJK. We describe the generation of global and local variables declarations (gVars and lVars) later.

Each QMC process declaration defines a single process containing local variable declarations and process body, structured with the process, begin and end key- words. Given a single CQP process definition as input,_TprogJKrewrites this defini- tion into a QMC process declaration.

For processes that are invoked from (that is, nested within) other processes the functionisInvoked (Definition 6.2) inserts a receive statement (Proc_ctrl?signal;, where Proc is the process name) that is used to signal the start of execution. For non-invoked processes the function isInvoked produces no output (the empty string

ε). The set of invoked processes Pin(C) (Definition 6.1) is determined by analysis of the structure of the CQP programC.

Definition 6.1 (Pin: Set of Invoked Processes). Pin(C) gives the set of names of invoked processes in the CQP programC. LetC=De, then this set is defined on the

structure ofC as follows Pin(D1, . . . , Dn) = [ iPin(Di) Pin(P rocN ame(˜x: ˜T) =P) =Pin(P) Pin(0) =∅ Pin((P1(˜x)kP2(˜y))) ={P1, P2} Pin(e?[˜e].P) =Pin(P) Pin(e![˜e].P) =Pin(P) Pin({e}.P) =Pin(P) Pin((νx:b[ ˜T])P) =Pin(P) Pin((qbit x)P) =Pin(P)

This set is used in the following formal definition of isInvoked.

Definition 6.2 (isInvoked: Invoked Process Function). isInvoked is a function from process names to QMC statements, where

isInvoked(Proc)7→    Proc_ctrl?signal; if Proc∈Pin(C) ε otherwise.

After any control statement has been added, the CQP process body is translated by the function_TprocJK.

Processes

The function _TprocJK, for translating the process body, is defined in Figure 6.6. The0process, denoting inaction, is rewritten to an empty string. The “invocation” of parallel processes (P1(x_e)k P2(y_e)) is achieved through signalling; as described in the previous section, processes that are invoked will await a signal before proceeding (determined by the function isInvoked) hence sending this signal allows the invoked process to begin execution.

CQP and QMC use different models of communication; in the former, commu- nication is synchronous, thus an input and output action must execute as one step. In contrast, communication in QMC is asynchronous, therefore an output action oc- curs strictly, but not necessarily immediately, before a corresponding input action. We simulate synchronous communication in QMC by requiring the sending process to wait for an acknowledgement from the receiving process. Thus, each CQP output action will be followed by an input action (_TexprJe_K_ack?ack) when translated, and similarly an output action (TexprJeK_ack!ack) will follow each CQP input action.

TprocJ0K=ε

TprocJ(P1(˜x)kP2(˜y))K=P1_ctrl!signal; P2_ctrl!signal;

TprocJe?[x1:T1,· · ·, xn:Tn].PK=

TexprJeK1?TvalJx1K· · ·TexprJeKn?TvalJxnK

TexprJeK_ack!ack;TprocJPK

TprocJe![e1,· · · , en].PK=e_1:=TexprJe1K;. . .e_n:=TexprJenK;

TexprJeK1!e_1;. . .TexprJeKn!e_n;

TexprJeK_ack?ack;TprocJPK

TprocJ{e}.PK=TexprJeKTprocJPK

TprocJ(νx:b[T])PK=TprocJPK

TprocJ(qbit x)PK=x := newqubit;TprocJPK

Figure 6.6. Translation of processes.

The communication models also differ in the fact that CQP channels are polyadic (allowing multiple subjects), whereas in QMC channels are monadic (having a single subject), hence it is necessary to separate CQP communication actions into multiple QMC actions. Because channels are typed in both languages, we cannot use a single channel name for all resulting actions. Instead, we introduce distinct channel names for each action. For example, a CQP channelcof aritynwill correspond to channels

c1, . . . , cn in QMC.

The use of distinct names also serves to prevent cross-talk and resulting deadlock. Consider, for example, two processes which can send on the same channel:

c![11, . . . ,1n].0k c![21, . . . ,2n].0.

If, in the translation, we use the same channel name for each action, we would get

c!11;. . .c!1n;kc!21;. . . ,c!2n;.

This could result in an output sequence such as 11,21,22,23,12, . . ., in which values appear from both processes.

Furthermore, QMC allows only variable names as the subject in output actions, hence it is necessary to assign any value or expression to be sent to a fresh variable before sending. For example, the CQP actionch![x,3] is translated to

ch_1 := x; ch1!ch_1; ch_2 := 3; ch2!ch_2; ch_ack?ack;

TexprJvK=TvalJvK

TexprJmeasuree1, . . . , enK=measTexprJe1K, . . . ,TexprJenK

TexprJe1, . . . , en∗=eK=TexprJeKTexprJe1K. . .TexprJenK

TexprJe1, . . . , en∗=e

f

K=TexprJeK_cond :=TexprJfK

if

::(_TexprJeK_cond = 1) ->TexprJe1, . . . , en∗=eKbreak;

::(_TexprJe_K_cond = 0) -> break; fi

TexprJe+eK=TexprJeK+TexprJeK

Figure 6.7. Translation of expressions.

this convention is extended to variables for the purpose of generalisation.

The creation of a new channel ((νc:_b[Te])) has no corresponding statement in the

QMC process body, however these constructs will be used later by the functionanGto collect channel and qubit declarations. In contrast, new qubit declarations ((qbitq)) have a corresponding initialisation statement in the QMC process body.

Expressions

CQP expressions consist of values, quantum measurements, quantum operations, and arithmetic expressions. We define the function _TexprJK in Figure 6.7 for the trans- lation of expressions. Values v are translated by TvalJK (defined later). Quantum

measurements on multiple qubits are possible in both languages, however they follow different conventions for the assignment of values to outcomes (decimal values 0,1,2,3 in CQP as opposed to bit tuples (0,0),(0,1),(1,0),(1,1) in QMC). We therefore re- strict the translation to single qubit measurements (on which the resulting values correspond) and note that this does not impact expressiveness.

There are two cases for quantum operators; conditional and non-conditional. In general, quantum operations are transcribed with the quantum operator first, followed by a comma separated list of qubit names. Controlled operationsUe_{are implemented} using anif construct, preceded by an assignment to allow for the evaluation of an arbitrary expression. We only consider bit values (generally resulting from single qubit measurements) for controlled operations, although this could be extended to allow any integer using the fact thatU4=Ifor all operators in the stabilizer formalism.

Addition is the only arithmetic operator formally defined in CQP, however the translation is easily extended to other arithmetic expressions.

v TvalJvK T TtypeJTK

x, q, c, . . . x,q,c, . . . Int integer

0,1, . . . 0, 1,. . . Qbit qubit

X,Y,Z X, Y,Z

b[T] channel ofTtypeJTK H,CNot,Ph had,cnot,ph

Figure 6.8. Translation of values and types.

Values and Types

The functions_TvalJKand_TtypeJKdefined in Figure 6.8 are used for the translation of values and types respectively. Variable names and literal values are left unchanged, while quantum operators are mapped to their QMC equivalents as per the definition. There is no translation for arbitrary quantum operators since only the Clifford op- erators are supported by QMC. The types Unit,Op(1),. . . corresponding to arbitrary operator types need not be translated since they are not used in QMC programs. Channel types_b[ ˜T] make a recursive call to translate the component types. Since we don’t allow channel mobility in the translation, declarations which are not allowed in QMC such aschannel of channel of Tare excluded.

Variable Declarations

QMC requires variables to be explicitly declared prior to use, either in a local process scope or globally. We take the approach of placing all variables in the global scope to avoid issues arising from the implementation of invocation. In particular, since channel names cannot be sent over QMC channels whereas other variables can, it is not possible to simulate inheritance of channel names. Instead we state the requirement that variable names must be unique, hence scoping in QMC will have no effect.

The functions gVars and lVars are used by _TprogJK in the translation of pro- grams to provide global and local variable declarations respectively for the QMC program. gVars inspects the CQP program for binding operators including c?[x_e:Te]

(gives declarations for each xi), (νx:b[Te]) (declares a series of channels xi of type

Ti), and (qbit x) (declares x as a qubit variable). Signalling channels for each pro- cess (procname_ctrl: channel of integer;) are also declared regardless of which processes will use them. Finally,gVars adds declarations for signaland ackwhich may be used for signalling and acknowledgments respectively.

Since we have chosen to declare all variables globally, the only use forlVars is to generate declarations for the intermediate assignments that arise from outputs and conditional unitary operations. An outputc![_ev] will results in declarationsc_i: T_i

whereTiare the types associated with channel c, and an operatorqe∗=U

e_{will result} in a declaratione_cond: TwhereT is the type of expressione.

Formally, we define functions anG (Definition 6.3) and anL (Definition 6.4) to determine the variables of programs and single processes respectively.

Definition 6.3(anG: Global variable analysis). LetIddenote a set of QMC identi- fiers andT a set of QMC types. Furthermore, letIT =Id×T. We define a function

anG:PC→2IT inductively as:

anG(D1. . . Dn) = {(signal,integer),(ack,integer)} ∪ S

ianG(Di)

anG(P roc(xe:Te) =P) = {(Proc_ctrl,channel of integer)}

∪anG(P)

anG(0) = ∅

anG((P1(˜x)kP2(˜x))) = ∅

anG(e?[e1:T1, . . . , en:Tn].P) = anG(P) ∪ S_i{(ei,TtypeJb[Ti]K)}

∪ {(e_ack,channel of integer)}

anG(e![˜e].P) = anG(P) anG({e}.P) = anG(P) anG((νx:b[T1, . . . , Tn])P) = anG(P) ∪ S i{(xi,TtypeJb[Ti]K)} anG((qbit x)P) = anG(P)∪ {(q,qbit)}

Definition 6.4 (anL: Local variable analysis). We define a partial function anL : PC *2IT inductively as: anL(P roc(˜x: ˜T) =P) = anL(P) anL(0) = ∅ anL((P1(˜x)k P2(˜x))) = ∅ anL(e?[˜e: ˜T].P) = anL(P) anL(e![e1, . . . , en].P) = {(e_i,TtypeJTiK)|1≤i≤n,`ei:Ti} ∪anL(P) anL({e}.P) = anL(P) anL({ee∗=e f<sub>}.P) = an</sub> L(P)∪ {(e_cond,TtypeJTK)| `f :T} anL((νx:b[T])P) = anL(P) anL((qbit x)P) = anL(P)

We now define a functionvars which takes a set of pairs (x, T) resulting fromanL andanG, and produces a QMC variable declaration statement:

Then, for a CQP program consisting of processesDe, we have

gVars(De) =vars(anG(De))

lVars(D) =vars(anL(D))