A Categorical Model for a Quantum Circuit Description Language (Extended   Abstract)

Francisco Rios (Dalhousie University; Halifax; Canada); Peter Selinger; (Dalhousie University; Halifax; Canada)

arXiv:1706.02630·quant-ph·March 5, 2018·QPL

A Categorical Model for a Quantum Circuit Description Language (Extended Abstract)

Francisco Rios (Dalhousie University, Halifax, Canada), Peter Selinger, (Dalhousie University, Halifax, Canada)

PDF

TL;DR

This paper introduces Proto-Quipper-M, a formal, type-safe fragment of Quipper that models quantum circuits within a categorical framework, enabling more general and rigorous descriptions of quantum computations.

Contribution

It formalizes Proto-Quipper-M with denotational and operational semantics, extending Quipper's capabilities to a broader categorical context.

Findings

01

Proto-Quipper-M is type-safe and sound.

02

The language models parameters and state categorically.

03

Proven properties include type safety, soundness, and adequacy.

Abstract

Quipper is a practical programming language for describing families of quantum circuits. In this paper, we formalize a small, but useful fragment of Quipper called Proto-Quipper-M. Unlike its parent Quipper, this language is type-safe and has a formal denotational and operational semantics. Proto-Quipper-M is also more general than Quipper, in that it can describe families of morphisms in any symmetric monoidal category, of which quantum circuits are but one example. We design Proto-Quipper-M from the ground up, by first giving a general categorical model of parameters and state. The distinction between parameters and state is also known from hardware description languages. A parameter is a value that is known at circuit generation time, whereas a state is a value that is known at circuit execution time. After finding some interesting categorical structures in the model, we then define…

Tables5

Table 1. Table 1: The types of Proto-Quipper-M

\begin{matrix} Types & A, B & : := & α ​ ∣ 0 ∣ ​ A + B ​ ∣ I ∣ ​ A \otimes B ​ ∣ A ⊸ B ∣! ​ A ​ ∣ 𝐧𝐚𝐭 ∣ ​ 𝐥𝐢𝐬𝐭 A ∣ Circ ​ (T, U) \\ Parameter types & P, R & : := & 0 ​ ∣ P + R ∣ ​ I ​ ∣ P \otimes R ∣! ​ A ​ ∣ 𝐧𝐚𝐭 ∣ ​ 𝐥𝐢𝐬𝐭 P ∣ Circ ​ (T, U) \\ Simple M-types & T, U & : := & α ​ ∣ I ∣ ​ T \otimes U \end{matrix}

Table 2. Table 2: The terms of Proto-Quipper-M

\begin{matrix} Terms & M, N & : := & x ​ ∣ ℓ ∣ ​ c ∣ let x = M in N \\ ∣ □_{A} ​ M ∣ ​ {left}_{A, B} M ​ ∣ {right}_{A, B} M ∣ ​ case M of {left x \to N ∣ right y \to P} \\ ∣ * ∣ M; N ∣ ⟨ M, N ⟩ ∣ let ⟨ x, y ⟩ = M in N ∣ λ x^{A} . M ∣ M N \\ ∣ lift M ∣ ​ force M ​ ∣ {box}_{T} M ∣ ​ apply (M, N) ∣ (\vec{ℓ}, C, {\vec{ℓ}}^{'}) \\ Label tuples & \vec{ℓ}, \vec{k} & : := & ℓ ∣ * ∣ ⟨ \vec{ℓ}, \vec{k} ⟩ \\ Values & V, W & : := & x ∣ ℓ ∣ c ∣ {left}_{A, B} V ∣ {right}_{A, B} V ∣ * ∣ ⟨ V, W ⟩ ∣ λ x^{A} . M ∣ lift M ∣ (\vec{ℓ}, C, {\vec{ℓ}}^{'}) \end{matrix}

Table 3. Table 3: The typing rules of Proto-Quipper-M (excerpt)

\begin{matrix} (var) \\ \overline{Φ, x : A; \emptyset ⊢ x : A} \end{matrix} \begin{matrix} (label) \\ \overline{Φ; ℓ : α ⊢ ℓ : α} \end{matrix} \begin{matrix} (const) \\ \overline{Φ; \emptyset ⊢ c : A_{c}} \end{matrix}

Table 4. Table 4: The interpretation of type derivations (excerpt)

\begin{matrix} [[Φ, x : A; \emptyset ⊢ x : A]] & = & [[Φ]] \otimes [[A]] \overset{⋄ \otimes id}{\to} I \otimes [[A]] \overset{≅}{\to} A \\ [[Φ; ℓ : α ⊢ ℓ : α]] & = & [[Φ]] \otimes [[α]] \overset{⋄ \otimes id}{\to} I \otimes [[α]] \overset{≅}{\to} α \\ [[Φ; \emptyset ⊢ lift M :! A]] & = & [[Φ]] \overset{𝐥𝐢𝐟𝐭 [[M]]}{\to}! [[A]] \\ [[Γ; Q ⊢ {box}_{T} M : Circ (T, U)]] & = & [[Γ]] \otimes [[Q]] \overset{[[M]]}{\to}! ([[T]] ⊸ [[U]]) \overset{≅}{\to} p (𝐌 ([[T]], [[U]])) \\ [[Φ, Γ_{1}, Γ_{2}; Q_{1}, Q_{2} ⊢ apply (M, N) : U]] & = & [[Φ]] \otimes [[Γ_{1}]] \otimes [[Γ_{2}]] \otimes [[Q_{1}]] \otimes [[Q_{2}]] \\ \overset{Δ \otimes id}{\to} [[Φ]] \otimes [[Φ]] \otimes [[Γ_{1}]] \otimes [[Γ_{2}]] \otimes [[Q_{1}]] \otimes [[Q_{2}]] \\ \overset{≅}{\to} ([[Φ]] \otimes [[Γ_{1}]] \otimes [[Q_{1}]]) \otimes ([[Φ]] \otimes [[Γ_{2}]] \otimes [[Q_{2}]]) \\ \overset{[[M]] \otimes [[N]]}{\to} p ​ (𝐌 ​ ([[T]], [[U]])) \otimes [[T]] \overset{𝐚𝐩𝐩𝐥𝐲}{\to} [[U]] \\ [[Φ; \emptyset ⊢ (\vec{ℓ}, C, {\vec{ℓ}}^{'}) : Circ (T, U)]] & = & [[Φ]] \overset{⋄}{\to} I \overset{p ​ (f ​ (\vec{ℓ}, C, {\vec{ℓ}}^{'}))}{\to} p ​ (𝐌 ​ ([[T]], [[U]])) \end{matrix}

Table 5. Table 5: The big-step semantics (excerpt)

\begin{matrix} \overline{(C, x) ⇓ Error} \end{matrix} \begin{matrix} \overline{(C, ℓ) ⇓ (C, ℓ)} \end{matrix} \begin{matrix} \overline{(C, c) ⇓ (C, c)} \end{matrix}

Equations52

A_{1} \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces

A_{1} \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces

A_{x} = {s \in A_{1} ∣ a (s) = x} .

A_{x} = {s \in A_{1} ∣ a (s) = x} .

{\bf bool}~{}=~{}\vbox{\lx@xy@svg{\hbox{\raise 0.0pt\hbox{\kern 5.5pt\hbox{\ignorespaces\ignorespaces\ignorespaces\hbox{\vtop{\kern 0.0pt\offinterlineskip\halign{\entry@#!@&&\entry@@#!@\cr\\\crcr}}}\ignorespaces{\hbox{\kern-5.5pt\raise 0.0pt\hbox{\hbox{\kern 0.0pt\raise 0.0pt\hbox{\hbox{\kern 3.0pt\raise 0.0pt\hbox{$\textstyle{2\ignorespaces\ignorespaces\ignorespaces\ignorespaces}$}}}}}}}\ignorespaces\ignorespaces\ignorespaces\ignorespaces{}{\hbox{\lx@xy@droprule}}\ignorespaces\ignorespaces\ignorespaces{\hbox{\kern 0.0pt\raise-12.84721pt\hbox{{}\hbox{\kern 0.0pt\raise 0.0pt\hbox{\hbox{\kern 3.0pt\hbox{\hbox{\kern 0.0pt\raise-2.43056pt\hbox{$\scriptstyle{{\rm id}}$}}}\kern 3.0pt}}}}}}\ignorespaces{\hbox{\kern 0.0pt\raise-22.69444pt\hbox{\hbox{\kern 0.0pt\raise 0.0pt\hbox{\lx@xy@tip{1}\lx@xy@tip{-1}}}}}}{\hbox{\lx@xy@droprule}}{\hbox{\lx@xy@droprule}}{\hbox{\kern-5.5pt\raise-32.13889pt\hbox{\hbox{\kern 0.0pt\raise 0.0pt\hbox{\hbox{\kern 3.0pt\raise 0.0pt\hbox{$\textstyle{2}$}}}}}}}\ignorespaces}}}}\ignorespaces}\qquad{\bf bit}~{}=~{}\vbox{\lx@xy@svg{\hbox{\raise 0.0pt\hbox{\kern 5.5pt\hbox{\ignorespaces\ignorespaces\ignorespaces\hbox{\vtop{\kern 0.0pt\offinterlineskip\halign{\entry@#!@&&\entry@@#!@\cr\\\crcr}}}\ignorespaces{\hbox{\kern-5.5pt\raise 0.0pt\hbox{\hbox{\kern 0.0pt\raise 0.0pt\hbox{\hbox{\kern 3.0pt\raise 0.0pt\hbox{$\textstyle{2\ignorespaces\ignorespaces\ignorespaces\ignorespaces}$}}}}}}}\ignorespaces\ignorespaces\ignorespaces\ignorespaces{}{\hbox{\lx@xy@droprule}}\ignorespaces\ignorespaces\ignorespaces{\hbox{\kern 0.0pt\raise-12.84721pt\hbox{{}\hbox{\kern 0.0pt\raise 0.0pt\hbox{\hbox{\kern 3.0pt\hbox{\hbox{\kern 0.0pt\raise-1.50694pt\hbox{$\scriptstyle{u}$}}}\kern 3.0pt}}}}}}\ignorespaces{\hbox{\kern 0.0pt\raise-22.69444pt\hbox{\hbox{\kern 0.0pt\raise 0.0pt\hbox{\lx@xy@tip{1}\lx@xy@tip{-1}}}}}}{\hbox{\lx@xy@droprule}}{\hbox{\lx@xy@droprule}}{\hbox{\kern-5.5pt\raise-32.13889pt\hbox{\hbox{\kern 0.0pt\raise 0.0pt\hbox{\hbox{\kern 3.0pt\raise 0.0pt\hbox{$\textstyle{1}$}}}}}}}\ignorespaces}}}}\ignorespaces}

{\bf bool}~{}=~{}\vbox{\lx@xy@svg{\hbox{\raise 0.0pt\hbox{\kern 5.5pt\hbox{\ignorespaces\ignorespaces\ignorespaces\hbox{\vtop{\kern 0.0pt\offinterlineskip\halign{\entry@#!@&&\entry@@#!@\cr\\\crcr}}}\ignorespaces{\hbox{\kern-5.5pt\raise 0.0pt\hbox{\hbox{\kern 0.0pt\raise 0.0pt\hbox{\hbox{\kern 3.0pt\raise 0.0pt\hbox{$\textstyle{2\ignorespaces\ignorespaces\ignorespaces\ignorespaces}$}}}}}}}\ignorespaces\ignorespaces\ignorespaces\ignorespaces{}{\hbox{\lx@xy@droprule}}\ignorespaces\ignorespaces\ignorespaces{\hbox{\kern 0.0pt\raise-12.84721pt\hbox{{}\hbox{\kern 0.0pt\raise 0.0pt\hbox{\hbox{\kern 3.0pt\hbox{\hbox{\kern 0.0pt\raise-2.43056pt\hbox{$\scriptstyle{{\rm id}}$}}}\kern 3.0pt}}}}}}\ignorespaces{\hbox{\kern 0.0pt\raise-22.69444pt\hbox{\hbox{\kern 0.0pt\raise 0.0pt\hbox{\lx@xy@tip{1}\lx@xy@tip{-1}}}}}}{\hbox{\lx@xy@droprule}}{\hbox{\lx@xy@droprule}}{\hbox{\kern-5.5pt\raise-32.13889pt\hbox{\hbox{\kern 0.0pt\raise 0.0pt\hbox{\hbox{\kern 3.0pt\raise 0.0pt\hbox{$\textstyle{2}$}}}}}}}\ignorespaces}}}}\ignorespaces}\qquad{\bf bit}~{}=~{}\vbox{\lx@xy@svg{\hbox{\raise 0.0pt\hbox{\kern 5.5pt\hbox{\ignorespaces\ignorespaces\ignorespaces\hbox{\vtop{\kern 0.0pt\offinterlineskip\halign{\entry@#!@&&\entry@@#!@\cr\\\crcr}}}\ignorespaces{\hbox{\kern-5.5pt\raise 0.0pt\hbox{\hbox{\kern 0.0pt\raise 0.0pt\hbox{\hbox{\kern 3.0pt\raise 0.0pt\hbox{$\textstyle{2\ignorespaces\ignorespaces\ignorespaces\ignorespaces}$}}}}}}}\ignorespaces\ignorespaces\ignorespaces\ignorespaces{}{\hbox{\lx@xy@droprule}}\ignorespaces\ignorespaces\ignorespaces{\hbox{\kern 0.0pt\raise-12.84721pt\hbox{{}\hbox{\kern 0.0pt\raise 0.0pt\hbox{\hbox{\kern 3.0pt\hbox{\hbox{\kern 0.0pt\raise-1.50694pt\hbox{$\scriptstyle{u}$}}}\kern 3.0pt}}}}}}\ignorespaces{\hbox{\kern 0.0pt\raise-22.69444pt\hbox{\hbox{\kern 0.0pt\raise 0.0pt\hbox{\lx@xy@tip{1}\lx@xy@tip{-1}}}}}}{\hbox{\lx@xy@droprule}}{\hbox{\lx@xy@droprule}}{\hbox{\kern-5.5pt\raise-32.13889pt\hbox{\hbox{\kern 0.0pt\raise 0.0pt\hbox{\hbox{\kern 3.0pt\raise 0.0pt\hbox{$\textstyle{1}$}}}}}}}\ignorespaces}}}}\ignorespaces}

2 \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces

2 \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces

2 \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces

2 \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces \ignorespaces

\begin{array}[]{lll}I&=&(1,(I))\\ A\otimes B&=&(A_{0}\times B_{0},(A_{x}\otimes B_{y})_{(x,y)\in A_{0}\times B_{0}})\\ A\mathbin{\multimap}B&=&(A_{0}\to B_{0},(C_{f})_{f}),\end{array}

\begin{array}[]{lll}I&=&(1,(I))\\ A\otimes B&=&(A_{0}\times B_{0},(A_{x}\otimes B_{y})_{(x,y)\in A_{0}\times B_{0}})\\ A\mathbin{\multimap}B&=&(A_{0}\to B_{0},(C_{f})_{f}),\end{array}

♭ (X, (A_{x})_{x \in X}) = x \in X \sum \overline{M} (I, A_{x}) .

♭ (X, (A_{x})_{x \in X}) = x \in X \sum \overline{M} (I, A_{x}) .

♭ (T ⊸ U) ≅ \overline{M} (I, T ⊸ U) ≅ \overline{M} (T, U) ≅ M (T, U) .

♭ (T ⊸ U) ≅ \overline{M} (I, T ⊸ U) ≅ \overline{M} (T, U) ≅ M (T, U) .

lift (f) :! A \to! B . f :! A \to B

lift (f) :! A \to! B . f :! A \to B

lift (f) : P \to! B . f : P \to B

lift (f) : P \to! B . f : P \to B

\begin{array}[]{lll}{\it size}&:&{\bf M}(T,U)\to\mathbb{N},\\ {\it print}&:&{\bf M}(T,U)\to{\rm Document},\\ {\it invert}&:&{\bf M}(T,T)\to{\bf M}(T,T)\end{array}

\begin{array}[]{lll}{\it size}&:&{\bf M}(T,U)\to\mathbb{N},\\ {\it print}&:&{\bf M}(T,U)\to{\rm Document},\\ {\it invert}&:&{\bf M}(T,T)\to{\bf M}(T,T)\end{array}

\overline{\overline{M}} (p (X), [[T]] ⊸ [[U]]) ≅ Set (X, ♭ ([[T]] ⊸ [[U]])) ≅ Set (X, M ([[T]], [[U]])),

\overline{\overline{M}} (p (X), [[T]] ⊸ [[U]]) ≅ Set (X, ♭ ([[T]] ⊸ [[U]])) ≅ Set (X, M ([[T]], [[U]])),

f

f

Γ; Q ⊢ λ x^{A} . M : A ⊸ B Γ, x : A; Q ⊢ M : B Φ, Γ_{1}, Γ_{2}; Q_{1}, Q_{2} ⊢ M N : B Φ, Γ_{1}; Q_{1} ⊢ M : A ⊸ B Φ, Γ_{2}; Q_{2} ⊢ N : A

Γ; Q ⊢ λ x^{A} . M : A ⊸ B Γ, x : A; Q ⊢ M : B Φ, Γ_{1}, Γ_{2}; Q_{1}, Q_{2} ⊢ M N : B Φ, Γ_{1}; Q_{1} ⊢ M : A ⊸ B Φ, Γ_{2}; Q_{2} ⊢ N : A

Φ; \emptyset ⊢ lift M :! A Φ; \emptyset ⊢ M : A Γ; Q ⊢ force M : A Γ; Q ⊢ M :! A

Φ; \emptyset ⊢ lift M :! A Φ; \emptyset ⊢ M : A Γ; Q ⊢ force M : A Γ; Q ⊢ M :! A

Γ; Q ⊢ box_{T} M : Circ (T, U) Γ; Q ⊢ M :! (T ⊸ U) Φ, Γ_{1}, Γ_{2}; Q_{1}, Q_{2} ⊢ apply (M, N) : U Φ, Γ_{1}; Q_{1} ⊢ M : Circ (T, U) Φ, Γ_{2}; Q_{2} ⊢ N : T

Γ; Q ⊢ box_{T} M : Circ (T, U) Γ; Q ⊢ M :! (T ⊸ U) Φ, Γ_{1}, Γ_{2}; Q_{1}, Q_{2} ⊢ apply (M, N) : U Φ, Γ_{1}; Q_{1} ⊢ M : Circ (T, U) Φ, Γ_{2}; Q_{2} ⊢ N : T

Φ; \emptyset ⊢ (ℓ, C, ℓ^{'}) : Circ (T, U) \emptyset; Q ⊢ ℓ : T \emptyset; Q^{'} ⊢ ℓ^{'} : U C \in M_{L} (Q, Q^{'})

Φ; \emptyset ⊢ (ℓ, C, ℓ^{'}) : Circ (T, U) \emptyset; Q ⊢ ℓ : T \emptyset; Q^{'} ⊢ ℓ^{'} : U C \in M_{L} (Q, Q^{'})

(C, λ x . M) ⇓ (C, λ x . M)

(C, λ x . M) ⇓ (C, λ x . M)

(C, M N) ⇓ (C^{'''}, W) (C, M) ⇓ (C^{'}, λ x . M^{'}) (C^{'}, N) ⇓ (C^{''}, V) (C^{''}, M^{'} [V / x]) ⇓ (C^{'''}, W) (C, M N) ⇓ Error (C, M) ⇓ otherwise

(C, M N) ⇓ (C^{'''}, W) (C, M) ⇓ (C^{'}, λ x . M^{'}) (C^{'}, N) ⇓ (C^{''}, V) (C^{''}, M^{'} [V / x]) ⇓ (C^{'''}, W) (C, M N) ⇓ Error (C, M) ⇓ otherwise

(C, lift M) ⇓ (C, lift M) (C, force M) ⇓ (C^{''}, V) (C, M) ⇓ (C^{'}, lift M^{'}) (C^{'}, M^{'}) ⇓ (C^{''}, V) (C, force M) ⇓ Error (C, M) ⇓ otherwise

(C, lift M) ⇓ (C, lift M) (C, force M) ⇓ (C^{''}, V) (C, M) ⇓ (C^{'}, lift M^{'}) (C^{'}, M^{'}) ⇓ (C^{''}, V) (C, force M) ⇓ Error (C, M) ⇓ otherwise

(C, box_{T} M) ⇓ (C^{'}, (ℓ, D, ℓ^{'})) (C, M) ⇓ (C^{'}, lift N) freshlabels (T) = (Q, ℓ) (id_{Q}, N ℓ) ⇓ (D, ℓ^{'})

(C, box_{T} M) ⇓ (C^{'}, (ℓ, D, ℓ^{'})) (C, M) ⇓ (C^{'}, lift N) freshlabels (T) = (Q, ℓ) (id_{Q}, N ℓ) ⇓ (D, ℓ^{'})

(C, box_{T} M) ⇓ Error (C, M) ⇓ (C^{'}, lift N) freshlabels (T) = (Q, ℓ) (id_{Q}, N ℓ) ⇓ otherwise (C, box_{T} M) ⇓ Error (C, M) ⇓ otherwise

(C, box_{T} M) ⇓ Error (C, M) ⇓ (C^{'}, lift N) freshlabels (T) = (Q, ℓ) (id_{Q}, N ℓ) ⇓ otherwise (C, box_{T} M) ⇓ Error (C, M) ⇓ otherwise

(C, apply (M, N)) ⇓ (C^{'''}, k^{'}) (C, M) ⇓ (C^{'}, (ℓ, D, ℓ^{'})) (C^{'}, N) ⇓ (C^{''}, k) append (C^{''}, k, ℓ, D, ℓ^{'}) = (C^{'''}, k^{'})

(C, apply (M, N)) ⇓ (C^{'''}, k^{'}) (C, M) ⇓ (C^{'}, (ℓ, D, ℓ^{'})) (C^{'}, N) ⇓ (C^{''}, k) append (C^{''}, k, ℓ, D, ℓ^{'}) = (C^{'''}, k^{'})

(C, (ℓ, D, ℓ^{'})) ⇓ (C, (ℓ, D, ℓ^{'}))

(C, (ℓ, D, ℓ^{'})) ⇓ (C, (ℓ, D, ℓ^{'}))

C

C

[[(C, M)]] = [[Q]] C [[Q^{''} \cup Q^{'}]] ≅ [[Q^{''}]] \otimes [[Q^{'}]] [[M]] \otimes id [[A]] \otimes [[Q^{'}]]

[[(C, M)]] = [[Q]] C [[Q^{''} \cup Q^{'}]] ≅ [[Q^{''}]] \otimes [[Q^{'}]] [[M]] \otimes id [[A]] \otimes [[Q^{'}]]

Peer Reviews

No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.

Videos

No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.

Full text

A Categorical Model for a Quantum Circuit

Description Language (Extended Abstract)

Francisco Rios and Peter Selinger Dalhousie University

Halifax, Canada

Abstract

Quipper is a practical programming language for describing families of quantum circuits. In this paper, we formalize a small, but useful fragment of Quipper called Proto-Quipper-M. Unlike its parent Quipper, this language is type-safe and has a formal denotational and operational semantics. Proto-Quipper-M is also more general than Quipper, in that it can describe families of morphisms in any symmetric monoidal category, of which quantum circuits are but one example. We design Proto-Quipper-M from the ground up, by first giving a general categorical model of parameters and state. The distinction between parameters and state is also known from hardware description languages. A parameter is a value that is known at circuit generation time, whereas a state is a value that is known at circuit execution time. After finding some interesting categorical structures in the model, we then define the programming language to fit the model. We cement the connection between the language and the model by proving type safety, soundness, and adequacy properties.

1 Introduction

Quipper is a functional programming language for quantum computing [4, 5]. What distinguishes Quipper from earlier quantum programming languages, such as the quantum lambda calculus [11], is that it is a circuit description language. This means two things: on the one hand, the language can be used to construct quantum circuits in a structured way, essentially by applying one gate at a time. On the other hand, the completed circuits themselves become data, which can be stored in variables and passed as components to subroutines, and on which meta-operations (such as circuit transformations, gate counts, inversion, error correction, etc) can be performed. These two levels of description (gate level operations and meta-operations on entire circuits) correspond quite closely to how many quantum algorithms are specified in the literature, and therefore provide a useful high-level paradigm for quantum programming.

Quipper is practical; it has been used to implement several large-scale quantum algorithms, generating circuits containing trillions of gates. However, there are some drawbacks. For efficiency reason, the original Quipper language was implemented as an embedded domain-specific language within the host language Haskell. As a result of mismatches between Quipper’s type system and that of Haskell, Quipper is not type-safe (there are some well-typed programs that lead to run-time errors). In particular, Haskell is unable to enforce linearity, i.e., the requirement that a quantum state cannot be used more than once (also known as the no-cloning property of quantum information). Moreover, as an embedded language, Quipper has no formal semantics; its behavior is only defined by its implementation. Giving a formal semantics of Quipper would require giving a formal semantics of Haskell, which is not feasible.

In this paper, we formalize a small, but useful fragment of Quipper called Proto-Quipper-M. This fragment is a stand-alone programming language (i.e., not embedded in a host language), and it has its own custom type system and semantics. This research fits into a larger program of formalizing portions of Quipper, and we use the name Proto-Quipper more generally to refer to any such formalized languages. For example, another version of Proto-Quipper has appeared in Ross’s Ph.D. thesis [10].

An important concept that arises in Quipper, and also in related settings such as hardware description languages, is the distinction between parameters and state. To understand the distinction, it is useful to keep in mind that Quipper is a language not just for describing individual quantum circuits, but parameterized families of quantum circuits: for example, in the case of Shor’s algorithm, one circuit for each integer to be factored. A parameter is a value that is known at circuit generation time, thus potentially picking out a member of the family of circuits. A state is a value that is known at circuit execution time, such as the state of a qubit. Naturally, a state can depend on a parameter, but since states are not known at circuit generation time, parameters cannot be a function of states.

Conceptually, Quipper’s gate level operations operate on states (for example, by applying a gate to a qubit), whereas its circuit level operations operate on parameters. One fundamental feature of Quipper is that there is only one kind of variable, which can hold both parameters and states (or any combination thereof, such as a list of qubits: here the length of the list is a parameter, and the individual qubits are states). We rely on the type system to ensure that parameters and states are used correctly. This distinguishes Quipper from related approaches, such as the QWire language [9], which enforce a strict separation between parameters and states by essentially defining two separate programming languages, one for parameters and one for states. The Quipper approach is more flexible, because the ability to mix parameters and states more freely gives the programmer access to useful abstractions, such as quantum data structures (like lists of qubits), or even pairs of entangled functions.

Our approach to the design of Proto-Quipper-M is from the ground up. We start by defining a general categorical model of parameters and state, and identifying a number of interesting categorical structures in the model. We then define the programming language to fit the model. One advantage of this approach is that our programming language is almost “correct by design”. In fact, as a result of our abstract approach, Proto-Quipper-M is slightly more general than Quipper, in the sense that it can describe families of morphisms of an arbitrary monoidal category, rather than just quantum circuits. We give computational meaning to the language by defining an operational semantics. Finally, we establish the correctness of the operational semantics by proving type safety, soundness, and adequacy properties.

2 A cartesian model of parameters and state

In this section, we describe a simplified categorical model of parameters and state, which will be convenient for introducing some useful terminology, and will be a stepping stone toward the more general model of Section 3. The model presented here is cartesian, rather than monoidal, and therefore could be used to model a language for describing classical, rather than quantum circuits. Nevertheless, several important notions will already be visible in this model.

2.1 The model ${\bf Set}^{{\bf 2}^{\it op}}$

Definition 2.1.

Let ${\bf 2}$ be the category with two objects, called [math] and $1$ , and a single non-identity arrow $0\rightarrow 1$ . Consider the functor category ${\bf Set}^{{\bf 2}^{\it op}}$ . Explicitly, an object of this category is a triple $A=(A_{0},A_{1},a)$ , where $A_{0},A_{1}$ are sets and $a:A_{1}\to A_{0}$ is a function. A morphism $f:A\to B$ is a commutative diagram

[TABLE]

We can think of an object $A=(A_{0},A_{1},a)$ as describing a family of sets, as follows. For each $x\in A_{0}$ , we define

[TABLE]

The set $A_{x}$ is called the fiber of $A$ over $x$ . Up to isomorphism, the object $A$ is uniquely determined by the family $(A_{x})_{x\in A_{0}}$ . We call the elements of $A_{0}$ parameters. We call the elements of $A_{x}$ states, and we say that the state is over $x$ . The elements of $A_{1}$ can therefore be identified with pairs $(x,s)$ , where $x\in A_{0}$ and $s\in A_{x}$ . We also call the pairs $(x,s)$ the generalized elements of $A$ .

The requirement that the diagram (1) commutes is exactly equivalent to the statement “states may depend on parameters, but parameters may not depend on states”. To see this, consider the effect of a morphism $f:A\to B$ on a parameter-state pair $(x,s)$ as defined above. Let $y=f_{0}(x)$ and $t=f_{1}(s)$ . Then $y\in B_{0}$ and $t\in B_{1}$ . Moreover, by the commutativity of (1), we have $y=f_{0}(x)=f_{0}(a(s))=b(f_{1}(s))=b(t)$ . In other words, for each $x\in A_{0}$ , $f_{1}:A_{1}\to B_{1}$ restricts to a function $f_{x}:A_{x}\to B_{f_{0}(x)}$ . We write $f(x,s)=(y,t)$ . We note that $y$ is only a function of $x$ , because $y=f_{0}(x)$ . Therefore, parameters may not depend on states. On the other hand, $t$ is a function of both $x$ and $s$ , because $t=f_{x}(s)$ . Therefore, states may depend on parameters and states.

Example 2.2.

We define some particular objects of ${\bf Set}^{{\bf 2}^{\it op}}$ . Let ${\bf bool}=(2,2,{\rm id})$ , where $2=\{0,1\}$ is a 2-element set and ${\rm id}$ is the identity function. Let ${\bf bit}=(1,2,u)$ , where $1=\{*\}$ is a 1-element set and $u:2\to 1$ is the unique function. In diagrams:

[TABLE]

The two generalized elements of ${\bf bool}$ are $(0,0)$ and $(1,1)$ , which we identify with “false” and “true”, respectively. The two generalized elements of ${\bf bit}$ are $(*,0)$ and $(*,1)$ , which we again identify with “false” and “true”.

So what is the difference between ${\bf bool}$ and ${\bf bit}$ ? Informally, a boolean is only a parameter and has no state, whereas a bit is only state and has no parameters. Note that there is an “identity” function $f:{\bf bool}\to{\bf bit}$ , mapping false to false and true to true. This function is given by the commutative diagram

[TABLE]

and it satisfies $f(0,0)=(*,0)$ and $f(1,1)=(*,1)$ . On the other hand, there exists no morphism $g:{\bf bit}\to{\bf bool}$ mapping false to false and true to true: the diagram

[TABLE]

cannot be made to commute. Therefore, a boolean can be used to initialize a bit, but not the other way round. This precisely captures our basic intuition about parameters and state.

Generalizing the example of ${\bf bool}$ and ${\bf bit}$ , we say that an object $A$ is a parameter object if it is of the form $(A,A,{\rm id})$ , and it is called a state object or simple if $A_{0}$ is a singleton. Note that ${\bf bool}$ is a parameter object and ${\bf bit}$ is a state object. Informally, a simple object corresponds to a single piece of data, rather than a parameterized family of data. Every object $A$ is isomorphic to a sum of simple objects, namely, $A\cong\sum_{x\in A_{0}}A_{x}$ .

2.2 A lambda calculus for parameters and state

Since the category ${\bf Set}^{{\bf 2}^{\it op}}$ is cartesian closed, we can interpret the simply-typed lambda calculus in it. We can also add sum types, base types such as ${\bf bool}$ and ${\bf bit}$ , and basic operations such as ${\bf init}:{\bf bool}\to{\bf bit}$ , all of which have obvious interpretations in the model. In this way, we obtain a very simple and semantically sound lambda calculus for the description of boolean (non-reversible) circuits. Moreover, the category ${\bf Set}^{{\bf 2}^{\it op}}$ is co-complete, which allows us to interpret inductive datatypes such as $\mathop{\bf list}\nolimits(A)$ using initial algebra semantics.

3 A categorical model of circuit families

While the model of Section 2.1 is useful for formalizing some basic intuitions about parameters and state, it is not yet a good model for describing families of quantum circuits. The main issue is that the model is cartesian, rather than monoidal. For example, there exist morphisms $\Delta:A\to A\times A$ for all objects $A$ , including state objects. This is not appropriate if we want to describe quantum circuits, where the no-cloning property prevents us from duplicating quantum states.

To see how to generalize the model ${\bf Set}^{{\bf 2}^{\it op}}$ to a monoidal setting, recall from (2) that the objects of ${\bf Set}^{{\bf 2}^{\it op}}$ can be equivalently described as pairs $(A_{0},(A_{x})_{x\in A_{0}})$ , where $A_{0}$ is a set and $(A_{x})_{x\in A_{0}}$ is a family of sets. Then a morphism $f:A\to B$ can be equivalently described as a pair $(f_{0},(f_{x})_{x\in A_{0}})$ , where $f_{0}:A_{0}\to B_{0}$ , and for each $x\in A_{0}$ , $f_{x}:A_{x}\to B_{f_{0}(x)}$ . We generalize this by considering $A_{x}$ to be an object of a monoidal category instead of a set.

3.1 The category ${\bf M}$ : generalized circuits

Before designing a circuit description language, we should be more precise about what we mean by a “circuit”. Rather than specifying a particular class of circuits, for example as graphical representations of sequences of gates, we take a more general and abstract point of view: for us, a circuit is simply a morphism in a (fixed but arbitrary) symmetric monoidal category. We therefore assume that a symmetric monoidal category ${\bf M}$ is given once and for all, and we call its morphisms generalized circuits. From this point of view, Proto-Quipper is simply a language for describing families of morphisms of ${\bf M}$ .

Remark 3.1.

We will regard the morphisms of ${\bf M}$ as concrete data. We should imagine that the category ${\bf M}$ is equipped with additional “meta-operations”, such as methods to print morphisms, determine their size or cost, invert them, and so on. These additional operations are external to the category ${\bf M}$ , and take the form of set-theoretic functions such as ${\it size}:{\bf M}(T,U)\to\mathbb{N}$ , ${\it print}:{\bf M}(T,U)\to{\rm Document}$ , ${\it invert}:{\bf M}(T,T)\to{\bf M}(T,T)$ . Here ${\bf M}(T,U)$ denotes a hom-set of the category ${\bf M}$ , and “ ${\rm Document}$ ” denotes a set of printable documents. If such meta-operations are present, we regard them as fixed and given.

3.2 The category $\overline{\bf M}$ : state

As the first step in constructing our model, we choose a full embedding ${\bf M}$ in some symmetric monoidal closed, product-complete category $\overline{\bf M}$ . This can be done in some fixed, but arbitrary way. For example, the Yoneda embedding has the required properties, using the Day tensor for the monoidal structure [3, 7]. However, we do not specify any particular way of constructing $\overline{\bf M}$ .

Remark 3.2.

Unlike the category ${\bf M}$ , we regard the category $\overline{\bf M}$ as abstract. It is monoidal closed, so we will be able to form higher-order objects such as $(A\mathbin{\multimap}B\otimes C)\mathbin{\multimap}D$ . However, we do not imagine morphisms between such higher-order objects as being concrete things that can be printed, measured, etc. Instead, we will only interact with such higher-order morphisms via the monoidal closed structure. In other words, the higher-order structure only exists as a kind of “scaffolding” to support lower-order concrete operations. By not specifying a particular way of constructing $\overline{\bf M}$ , but only specifying its properties, we ensure that we will treat this category in the abstract, i.e., none of the theorems we will prove depend on any properties of $\overline{\bf M}$ other than those that were stated.

3.3 The category $\overline{\overline{\bf M}}$ : parameters

We now define the category $\overline{\overline{\bf M}}$ , which will serve as a model for parameters and state, and which will be the main carrier of the categorical semantics of our circuit description language.

Definition 3.3.

The category $\overline{\overline{\bf M}}$ has the following objects and morphisms:

•

An object is a pair $A=(X,(A_{x})_{x\in X})$ , where $X$ is a set and $(A_{x})_{x\in X}$ is an $X$ -indexed family of objects of $\overline{\bf M}$ . As before, we call $A_{x}$ the fiber of $A$ over $x$ . We sometimes write $X=A_{0}$ .

•

A morphism $f:(X,(A_{x})_{x\in X})\to(Y,(B_{y})_{y\in Y})$ is a pair $(f_{0},(f_{x})_{x\in X})$ , where $f_{0}:X\to Y$ is a function and each $f_{x}:A_{x}\to B_{f_{0}(x)}$ is a morphism of $\overline{\bf M}$ .

This category is surprisingly rich in structure. We begin by stating some of its most fundamental properties. It is perhaps not very surprising that $\overline{\overline{\bf M}}$ has coproducts and a symmetric monoidal structure. What is perhaps more surprising is that it is also monoidal closed.

Proposition 3.4.

The category $\overline{\overline{\bf M}}$ has an initial object, given by $0=(\emptyset,\emptyset)$ , where $\emptyset$ denotes both the empty set and the empty family. It also has coproducts, given by $A+B=(A_{0}+B_{0},(C_{i})_{i})$ , where $A_{0}+B_{0}=\{(0,x)\mid x\in A_{0}\}\cup\{(1,y)\mid y\in B_{0}\}$ is the disjoint union of sets, and $C_{(0,x)}=A_{x}$ and $C_{(1,y)}=B_{y}$ . The category $\overline{\overline{\bf M}}$ also has infinite coproducts, defined in an analogous manner. Indeed, it is well-known that $\overline{\overline{\bf M}}$ is the free coproduct completion of $\overline{\bf M}$ .

Proposition 3.5.

The category $\overline{\overline{\bf M}}$ is symmetric monoidal closed with the following structure:

[TABLE]

where $C_{f}=\prod_{x\in A_{0}}(A_{x}\mathbin{\multimap}B_{f(x)}).$ Here, of course, $A_{0}\to B_{0}$ denotes the set of all functions from $A_{0}$ to $B_{0}$ , and $A_{x}\mathbin{\multimap}B_{y}$ denotes the exponential object in the monoidal closed category $\overline{\bf M}$ . Note that in the definition of $C_{f}$ , we have used the fact that $\overline{\bf M}$ has products.

We note that the category ${\bf Set}^{{\bf 2}^{\it op}}$ of Section 2 is a special case; indeed, if the initial monoidal category is ${\bf M}={\bf Set}$ , then it is already closed, so we can take $\overline{\bf M}={\bf Set}$ , and we get $\overline{\overline{\bf M}}\simeq{\bf Set}^{{\bf 2}^{\it op}}$ .

3.4 Properties of objects

The concepts of parameter and state objects can be defined analogously to Section 2.1. Namely, an object $A\in\overline{\overline{\bf M}}$ is a parameter object if each fiber is the tensor unit $I$ , i.e., if $A=(X,(I)_{x\in X})$ . An object $A\in\overline{\overline{\bf M}}$ is a state object or simple if $A_{0}\cong 1$ . Note that the full subcategory of $\overline{\overline{\bf M}}$ of simple objects is equivalent to $\overline{\bf M}$ . An object $A\in\overline{\overline{\bf M}}$ is an M-object if every fiber belongs to the category ${\bf M}$ (regarded as a full subcategory of $\overline{\bf M}$ ). Thus, M-objects denote families of objects of ${\bf M}$ . Note that the full subcategory of $\overline{\overline{\bf M}}$ of simple M-objects is equivalent to ${\bf M}$ . The terminology “simple” is justified by the fact that every object $A=(X,(A_{x})_{x})$ of $\overline{\overline{\bf M}}$ can be written, essentially uniquely, as a coproduct of simple objects.

More systematically, note that we have functors ${\bf Set}\xrightarrow{p}\overline{\overline{\bf M}}$ and ${\bf M}\stackrel{{\scriptstyle i}}{{\hookrightarrow}}\overline{\bf M}\stackrel{{\scriptstyle j}}{{\hookrightarrow}}\overline{\overline{\bf M}}$ , where $p(X)=(X,(I)_{x})$ , $i$ is the canonical inclusion, and $j(A)=(1,(A))$ . Then $A$ is a parameter object iff it is in the image of the functor $p$ , a simple object iff it is in the image of $j$ , and a simple M-object iff it is in the image of $j\circ i$ .

3.5 Some basic types and operations

The coproducts of $\overline{\overline{\bf M}}$ permit us to construct a parameter object ${\bf bool}=I+I$ . This object is equipped with morphisms ${\bf true},{\bf false}:I\to{\bf bool}$ and an if-then-else construction, i.e., an operation mapping a pair of morphisms $f,g:A\to B$ to a morphism $h:{\bf bool}\otimes A\to B$ satisfying appropriate conditions. Similarly, there is an object ${\bf nat}=(\mathbb{N},(I)_{n})$ , and indeed there is a parameter object $p(X)$ corresponding to every set $X$ , arising from the functor $p:{\bf Set}\to\overline{\overline{\bf M}}$ .

Assume the category ${\bf M}$ has some distinguished objects, say ${\bf bit}$ and ${\bf qubit}$ , and some distinguished morphisms, for example $H:{\bf qubit}\to{\bf qubit}$ and ${\bf meas}:{\bf qubit}\to{\bf bit}$ . The latter are called gates. Then there are corresponding objects and morphisms in $\overline{\overline{\bf M}}$ , arising from the embedding ${\bf M}\hookrightarrow\overline{\overline{\bf M}}$ .

3.6 Inductive types

Recall that a functor $F$ on a category is continuous if it preserves colimits of diagrams of the form $A_{0}\to A_{1}\to\ldots$ . In a category with colimits, every continuous functor has an initial algebra. This is the basis for the categorical semantics of inductive datatypes. Unfortunately, the category $\overline{\overline{\bf M}}$ only has coproducts, and not necessarily all colimits, so we cannot in general expect initial algebras of continuous functors to exist. Nevertheless, for many functors of interest, the required initial algebras exist. For example, consider the functor $F(X)=I+A\otimes X$ . Its initial algebra is the infinite coproduct $I+A+A\otimes A+A\otimes A\otimes A+\ldots$ . We denote it as $\mathop{\bf list}\nolimits(A)$ , the type of lists of $A$ . An analogous construction also works for other functors constructed from $+$ and $\otimes$ . Another example is the object ${\bf nat}$ of natural numbers, which arises as the initial algebra of $F(X)=I+X$ , and is also isomorphic to $\mathop{\bf list}\nolimits(I)$ .

3.7 Boxing

Proposition 3.6.

The functor $p:{\bf Set}\to\overline{\overline{\bf M}}$ , defined in Section 3.4, has a right adjoint $\flat:\overline{\overline{\bf M}}\to{\bf Set}$ . It is given as follows, where $\overline{\bf M}(A,B)$ denotes a hom-set of the category $\overline{\bf M}$ :

[TABLE]

An important special case arises for simple M-objects $T$ and $U$ . In this case, we have

[TABLE]

In other words, $\flat(T\mathbin{\multimap}U)$ is just a hom-set of the category ${\bf M}$ , i.e., a set of generalized circuits. We would like to be able to use completed circuits as parameters in the construction of other circuits, i.e., we would like there to be a parameter object whose elements are circuits. Such an object is $p({\bf M}(T,U))\cong p(\flat(T\mathbin{\multimap}U))$ . This motivates the following definition:

Definition 3.7.

The functor ${!}:\overline{\overline{\bf M}}\to\overline{\overline{\bf M}}$ is defined by ${!}=p\circ\flat.$ Since $p$ and $\flat$ are adjoints, the functor ${!}$ is a comonad on the category $\overline{\overline{\bf M}}$ [7]. We call it the boxing comonad. It is equipped with a natural transformation $\mathop{\bf force}\nolimits:{!}A\to A$ as well as a lifting operation

[TABLE]

Remark 3.8.

From (5), we have an isomorphism $\mathop{\bf box}\nolimits:{!}(T\mathbin{\multimap}U)\to p({\bf M}(T,U))$ for simple M-objects $T$ and $U$ . We denote its inverse by $\mathop{\bf unbox}\nolimits$ . It will also be convenient to consider an operation $\mathop{\bf apply}\nolimits:p({\bf M}(T,U))\otimes T\to U$ , which is definable from $\mathop{\bf unbox}\nolimits$ using $\mathop{\bf force}\nolimits$ and the monoidal closed structure.

Remark 3.9.

In the category $\overline{\overline{\bf M}}$ , every parameter object $P$ is isomorphic to an object of the form ${!}A$ . We can therefore generalize the lift operation to all parameter objects:

[TABLE]

Theorem 3.10.

The category $\overline{\overline{\bf M}}$ , together with the adjunction given by $p:{\bf Set}\to\overline{\overline{\bf M}}$ and $\flat:\overline{\overline{\bf M}}\to{\bf Set}$ , forms a linear-non-linear model in the sense of Benton [2, 8].

3.8 Meta-operations on circuits

In Remark 3.1, we considered that the category ${\bf M}$ may be equipped with additional meta-operations on generalized circuits, such as

[TABLE]

Note that these operations are external to the category ${\bf M}$ , i.e., they are not morphisms of ${\bf M}$ , but set-theoretic functions. Using the boxing monad “ ${!}$ ”, these meta-operations can be internalized in the category $\overline{\overline{\bf M}}$ . Namely, given the above operations, the following are morphisms of $\overline{\overline{\bf M}}$ , where $T,U$ are simple M-objects:

$\begin{array}[]{lll}{\bf size}&=&{!}(T\mathbin{\multimap}U)\xrightarrow{~{}\mathop{\bf box}\nolimits~{}}p({\bf M}(T,U))\xrightarrow{~{}p({\it size})~{}}p(\mathbb{N})\xrightarrow{~{}\cong~{}}{\bf nat}\\ {\bf print}&=&{!}(T\mathbin{\multimap}U)\xrightarrow{~{}\mathop{\bf box}\nolimits~{}}p({\bf M}(T,U))\xrightarrow{~{}p({\it print})~{}}p({\rm Document})\\ {\bf invert}&=&{!}(T\mathbin{\multimap}T)\xrightarrow{~{}\mathop{\bf box}\nolimits~{}}p({\bf M}(T,T))\xrightarrow{~{}p({\it invert})~{}}p({\bf M}(T,T))\xrightarrow{~{}\mathop{\bf unbox}\nolimits~{}}{!}(T\mathbin{\multimap}T)\end{array}$

This precisely captures our intuition that “boxed” circuits are concrete data that can be operated upon at circuit generation time.

4 Towards a circuit description language

4.1 Overview

As explained in the introduction, we will design a programming language for circuit description by making the language fit the denotational model. We start with a brief overview of all the features that will be added to the language. The formal definitions will follow in Section 4.3.

Since the category $\overline{\overline{\bf M}}$ is symmetric monoidal closed with coproducts, a standard linear lambda calculus with sum types can be interpreted in it. Basic types such as ${\bf bool}$ , ${\bf bit}$ and ${\bf qubit}$ (the latter two if present in the category ${\bf M}$ of generalized circuits) can also be added to the language, along with the associated terms (such as ${\bf true}$ , ${\bf false}$ , an if-then-else construction, and any basic gates that are present in the category ${\bf M}$ ). Moreover, certain inductive types such as $\mathop{\bf list}\nolimits(A)$ and ${\bf nat}$ exist in the model and therefore can be added to the language. The language can further be equipped with a type operation “ ${!}$ ” and terms “ $\mathop{\rm lift\,}\nolimits$ ”, “ $\mathop{\rm force\,}\nolimits$ ”, “ $\mathop{\rm box}\nolimits$ ”, and “ $\mathop{\rm apply}\nolimits$ ”, arising from their categorical counterparts in Section 3.7.

Certain types of the language will be designated as parameter types, simple types, and/or M-types. Their interpretation in the model will of course be parameter objects, simple objects, and/or M-objects, respectively. In Quipper, M-types were called quantum data types, but that name does not seem appropriate in the context of generalized circuits. We have not come up with a better name for them and are stuck with “M-types” for now.

Remark 4.1.

Our claim that the resulting programming language is a language for describing families of circuits is justified by the following observation. Suppose $\Phi\vdash N:T\mathbin{\multimap}U$ is a valid typing judgement, where $\Phi$ is a parameter context (i.e., a context where each type is a parameter type), and $T$ and $U$ are simple M-types. Then the interpretation of this typing judgement will be a morphism $[[N]]:p(X)\to[[T]]\mathbin{\multimap}[[U]]$ of the category $\overline{\overline{\bf M}}$ , where $p(X)=[[\Phi]]$ is a parameter object and $[[T]]$ and $[[U]]$ are simple M-objects. We have:

[TABLE]

where the first isomorphism uses the fact that $\flat$ is the right adjoint of $p$ , and the second isomorphism arises from (5). Therefore, the interpretation of $N$ literally yields a function from $X$ to ${\bf M}([[T]],[[U]])$ , i.e., a parameterized family of generalized circuits.

4.2 Labelled circuits

As explained in Section 3.1, we assume that a symmetric monoidal category ${\bf M}$ of generalized circuits has been fixed once and for all. To make it more convenient for our programming language to manipulate morphisms of ${\bf M}$ , it is useful to equip ${\bf M}$ with an additional labelling structure, which we now define.

Let us assume a fixed given set ${\cal W}$ of wire types, together with an interpretation function $[[-]]:{\cal W}\to|{\bf M}|$ , assigning an object of ${\bf M}$ to every wire type. In practical examples, we will sometimes assume that the set ${\cal W}$ contains two wire types called ${\bf bit}$ and ${\bf qubit}$ , but in general the set of wire types is arbitrary. We often denote wire types by Greek letters such as $\alpha$ and $\beta$ . Let ${\cal L}$ be a fixed countably infinite set of labels, which we assume to be totally ordered. We often denote labels by the letters $\ell$ or $k$ . A label context is a function from some finite set of labels to wire types. We write label contexts as $Q=\ell_{1}:\alpha_{1},\ldots,\ell_{n}:\alpha_{n}$ . To each label context $Q=\ell_{1}:\alpha_{1},\ldots,\ell_{n}:\alpha_{n}$ , we associate the object $[[Q]]=[[\alpha_{1}]]\otimes\ldots\otimes[[\alpha_{n}]]$ of ${\bf M}$ , where $\ell_{1}<\ell_{2}<\ldots<\ell_{n}$ . In case $Q=\emptyset$ , we set $[[Q]]=I$ .

Definition 4.2 (Labelled circuits).

Let ${\bf M}$ be a given symmetric monoidal category, and let ${\cal W}$ , ${\cal L}$ , and the function $[[-]]:{\cal W}\to|{\bf M}|$ be given as above. The symmetric monoidal category ${\bf M}_{{\cal L}}$ of labelled circuits is defined as follows:

•

The objects of ${\bf M}_{{\cal L}}$ are label contexts.

•

A morphism $f:Q\to Q^{\prime}$ in ${\bf M}_{{\cal L}}$ is by definition a morphism $f:[[Q]]\to[[Q^{\prime}]]$ .

Identities and composition are defined so that $[[-]]:{\bf M}_{{\cal L}}\to{\bf M}$ is a full and faithful functor. We equip ${\bf M}_{{\cal L}}$ with the unique (up to natural isomorphism) symmetric monoidal structure making this functor symmetric monoidal.

Note that if $Q$ and $Q^{\prime}$ have disjoint domains, then $Q\otimes Q^{\prime}\cong Q\cup Q^{\prime}$ , i.e., the tensor of disjoint label contexts is given by their union. Two label contexts can always be made disjoint up to isomorphism by renaming their labels. We can visualize the morphisms of ${\bf M}_{{\cal L}}$ as generalized circuits with labelled and typed inputs and outputs, for example

[TABLE]

Remark 4.3.

Although it was convenient to assume that the set of labels is totally ordered, Definition 4.2 is actually independent of the particular order chosen. Specifically, if we change the ordering of the labels, the resulting category ${\bf M}_{{\cal L}}$ will be isomorphic to the original one.

4.3 The syntax of Proto-Quipper-M

The types of Proto-Quipper-M are shown in Table 1. Here, $\alpha$ ranges over the set ${\cal W}$ of wire types. ${\rm Circ}(T,U)$ is the type of generalized circuits with inputs $T$ and outputs $U$ . Denotationally, this type is the same as ${!}(T\mathbin{\multimap}U)$ , but it will receive special treatment in the operational semantics.

The terms of Proto-Quipper-M are shown in Table 2. Here, $x$ ranges over a countable set of variables, $\ell$ ranges over the set ${\cal L}$ of labels, and $c$ ranges over a given set of constants. We assume that these sets are pairwise disjoint. A label is a symbolic representation of a circuit state: it is a pointer to an output of a labelled circuit. Constants have a fixed interpretation, which depends on the chosen category ${\bf M}$ . For example, it will be convenient to assume constants for built-in gates such as $H:{\bf qubit}\mathbin{\multimap}{\bf qubit}$ . If the category ${\bf M}$ is equipped with meta-operations as in Remark 3.1, then these can be represented by constants such as ${\bf size}:{\rm Circ}(T,U)\to{\bf nat}$ , ${\bf invert}:{\rm Circ}(T,U)\to{\rm Circ}(U,T)$ , and so on. Most of the other terms follow standard lambda calculus conventions. The operator $\Box_{A}:0\to A$ represents the unique function from the empty type to any type $A$ . The term $(\vec{\ell},C,\vec{\ell}^{\prime})$ represents a boxed circuit, i.e., a value of type ${\rm Circ}(T,U)$ . Specifically, $C$ is a morphism of the category ${\bf M}_{{\cal L}}$ , representing a generalized circuit, and $\vec{\ell}$ and $\vec{\ell}^{\prime}$ are label tuples, establishing an interface between the inputs and outputs of $C$ and the types $T$ and $U$ . Terms of the form $(\vec{\ell},C,\vec{\ell}^{\prime})$ are not intended to be written directly by users of the programming language. Rather, such terms represent values that are computed by the programming language.

A variable context is a function from a finite set of variables to types. We write a variable context as $\Gamma=x_{1}:A_{1},\ldots,x_{n}:A_{n}$ . A variable context in which all types are parameter types is called a parameter context; we sometimes denote parameter contexts by $\Phi$ . A label context was already defined in Section 4.2, and is a function from a finite set of labels to wire types. As usual, we write $\Gamma,\Delta$ to denote the union of contexts, provided that they have disjoint domain.

A typing judgement is of the form $\Gamma;Q\vdash M:A$ , and it informally means that if the variables and labels have the types declared in $\Gamma$ and $Q$ , then $M$ is well-typed of type $A$ . A selection of the typing rules for Proto-Quipper-M is shown in Table 3. Most of the typing rules resemble the standard rules for a linear lambda calculus; we will comment on a few particular features of the type system. Note that in the typing rules, $\Phi$ stands for a parameter context, whereas $\Gamma$ denotes an arbitrary variable context (which can contain both parameter types and non-parameter types). There is no formal distinction between these two kinds of contexts, so it is entirely possible to have a type derivation where a given type is part of $\Phi$ in one rule and part of $\Gamma$ in another. Let us call a variable whose type is not a parameter type a linear variable. The type system enforces that labels and linear variables are used exactly once, whereas parameters may be used any number of times or not at all. In the typing rule for constants, we have assumed that each constant $c$ is equipped with a fixed type $A_{c}$ .

4.4 Categorical semantics

Because of the preparatory work we did in Section 3, the categorical semantics of Proto-Quipper-M is now straightforward. The semantics associates to each type $A$ an object $[[A]]$ of the category $\overline{\overline{\bf M}}$ in the obvious way: the interpretation $[[\alpha]]$ of a wire type is assumed given, and each connective is interpreted as “itself”, for example, $[[0]]=0$ , $[[A+B]]=[[A]]+[[B]]$ , and so on. We also set $[[{\rm Circ}(T,U)]]=p({\bf M}([[T]],[[U]]))$ . If $\Gamma=x_{1}:A_{1},\ldots,x_{n}:A_{n}$ is a typing context, we write $[[\Gamma]]=[[A_{1}]]\otimes\ldots\otimes[[A_{n}]]$ .

Next, we associate a morphism $[[\Gamma;Q\vdash M:A]]:[[\Gamma]]\otimes[[Q]]\to[[A]]$ to each valid typing judgement. By abuse of notation, we sometimes denote this simply as $[[M]]$ . We assume that each constant $c$ of type $A_{c}$ is interpreted by a given fixed morphism $[[c]]:I\to[[A_{c}]]$ . The interpretation of type derivations is defined by induction on the typing rules. For space reasons, we only show part of the interpretation in Table 4. The interpretation uses maps $\diamond:P\to I$ and $\Delta:P\to P\otimes P$ , which exist in the category $\overline{\overline{\bf M}}$ whenever $P$ is a parameter object. Each judgement of the form $Q\vdash\vec{\ell}:T$ induces an isomorphism $[[\vec{\ell}]]:[[Q]]\to[[T]]$ , from which we can define a morphism $f(\vec{\ell},C,\vec{\ell}^{\prime})=[[\vec{\ell}^{\prime}]]\circ C\circ[[\vec{\ell}]]^{-1}:[[T]]\to[[U]]$ . This is used in the last rule in Table 4.

5 Operational semantics

5.1 Evaluation rules

We define the operational semantics of Proto-Quipper-M as a big-step semantics [6]. A configuration is a pair $(C,M)$ of a labelled circuit $C$ and a term $M$ . Recall that a labelled circuit is, by definition, a morphism of the category ${\bf M}_{{\cal L}}$ . Intuitively, $C$ is the circuit “currently being constructed” when the term $M$ is run. A configuration is a value configuration if $M$ is a value. Evaluation takes the form of an evaluation relation $(C,M)\Downarrow(C^{\prime},V)$ . Its intuitive meaning is: when the term $M$ is evaluated in the context of a partially constructed circuit $C$ , then it produces a circuit $C^{\prime}$ (obtained from $C$ by appending zero or more gates) and a value $V$ . We also define an error relation $(C,M)\Downarrow{\rm Error}$ , meaning that the evaluation of $M$ in the context of the circuit $C$ produces a run-time error. Examples of run-time errors are:

•

Run-time type errors. For example, evaluating an application $MN$ , where $M$ is not a function, or a projection $\pi_{1}M$ , when $M$ is not a pair.

•

Unbound variable or label. For example, using a variable $x$ that has not been defined, or trying to append a gate to a wire $\ell$ that does not exist.

•

Cloning errors. For example, trying to append a $2$ -input gate to wires $\ell$ and $\ell^{\prime}$ , where $\ell=\ell^{\prime}$ .

The evaluation and error relations are defined recursively. A selection of the evaluation rules are shown in Table 5, using some notations which we now explain. As usual, $M[V/x]$ denotes capture-avoiding substitution, i.e., the result of replacing the variable $x$ by the value $V$ in the term $M$ . In the hypotheses of several rules, we have used the notation “ $(C,M)\Downarrow{\rm otherwise}$ ”. This is an abbreviation for $(C,M)\Downarrow(C^{\prime},W)$ , where $W$ is not of one of the explicit forms mentioned in a previous rule for the same configuration. For example, in the rules for $\mathop{\rm force\,}\nolimits$ , $(C,M)\Downarrow{\rm otherwise}$ means $(C,M)\Downarrow(C^{\prime},W)$ where $W$ is not of the form $\mathop{\rm lift\,}\nolimits M^{\prime}$ . All such “ ${\rm otherwise}$ ” cases yield run-time type errors.

Most of the evaluation rules are those of a standard call-by-value lambda calculus. The rules that do all of the interesting “work” of Proto-Quipper-M are those for “ $\mathop{\rm box}\nolimits$ ” and “ $\mathop{\rm apply}\nolimits$ ”. Namely, these rules are responsible for the construction of circuits. They rely on two auxiliary functions, which we now explain. The rules for “ $\mathop{\rm box}\nolimits$ ” use a function $\mathop{\it freshlabels}\nolimits$ . Given a simple M-type $T$ , the operation $\mathop{\it freshlabels}\nolimits(T)$ returns a pair $(Q,\vec{\ell})$ of a label context and a label tuple such that $Q\vdash\vec{\ell}:T$ . Moreover, the labels in $\vec{\ell}$ are chosen to be fresh, which means that they do not occur in $N$ .

The rule for “ $\mathop{\rm apply}\nolimits$ ” uses a function $\mathop{\it append}\nolimits$ , defined as follows. First, let us say that two boxed circuits $(\vec{\ell},D,\vec{\ell})$ and $(\vec{k},D^{\prime},\vec{k}^{\prime})$ are equivalent, in symbols $(\vec{\ell},D,\vec{\ell})\cong(\vec{k},D^{\prime},\vec{k}^{\prime})$ , if they only differ by a renaming of labels. Given labelled circuits $C:Q_{0}\to Q_{1}$ and $D:Q_{2}\to Q_{3}$ and label tuples $\vec{k}$ , $\vec{\ell}$ , and $\vec{\ell}^{\prime}$ , the operation $\mathop{\it append}\nolimits(C,\vec{k},\vec{\ell},D,\vec{\ell}^{\prime})$ finds $D^{\prime}$ and $\vec{k}^{\prime}$ such that $(\vec{k},D^{\prime},\vec{k}^{\prime})\cong(\vec{\ell},D,\vec{\ell}^{\prime})$ , and such that the labels in $\vec{k}^{\prime}$ are fresh. It returns $(C^{\prime},\vec{k}^{\prime})$ , where $C^{\prime}$ is the labelled circuit obtained by connecting the inputs of $D^{\prime}$ to the matching outputs of $C$ like this:

[TABLE]

5.2 Safety properties

The operational semantics satisfies the following safety properties: a well-typed configuration never produces a run-time error, and if it reduces to a value configuration, then the latter is well-typed of the same type. To make this more precise, we first define a notion of typing for configurations.

Definition 5.1.

Let $Q,Q^{\prime}$ be label contexts, $(C,M)$ a configuration, and $A$ a type. We say that $(C,M)$ is well-typed with input labels $Q$ , output labels $Q^{\prime}$ , and type $A$ , in symbols $Q\vdash(C,M):A;Q^{\prime},$ if there exists $Q^{\prime\prime}$ disjoint from $Q^{\prime}$ such that $C:Q\to Q^{\prime\prime}\cup Q^{\prime}$ and $\emptyset;Q^{\prime\prime}\vdash M:A$ .

Proposition 5.2 (Subject reduction).

If $Q\vdash(C,M):A;Q^{\prime}$ and $(C,M)\Downarrow(C^{\prime},V)$ , then $Q\vdash(C^{\prime},V):A;Q^{\prime}$ .

Proposition 5.3 (Error freeness).

If $Q\vdash(C,M):A;Q^{\prime}$ , then $(C,M)\not\hskip 0.45pt\Downarrow{\rm Error}$ .

While the statement of these properties is succinct, the proofs are intricate and require a number of auxiliary lemmas, which we omit. Since our language does not have a recursion operator, we also have:

Proposition 5.4 (Termination).

If $Q\vdash(C,M):A;Q^{\prime}$ , then there exists $(C^{\prime},V)$ such that $(C,M)\Downarrow(C^{\prime},V)$ .

5.3 Soundness properties

While the safety properties of Section 5.2 relate the evaluation rules to the typing rules, the following soundness properties relate the evaluation rules to the categorical semantics. We first extend the categorical semantics from well-typed terms to well-typed configurations.

Definition 5.5.

To each well-typed configuration $Q\vdash(C,M):A;Q^{\prime}$ , we associate a morphism $[[(C,M)]]:[[Q]]\to[[A]]\otimes[[Q^{\prime}]]$ of the category $\overline{\overline{\bf M}}$ as follows. By definition of well-typed configuration, there exists a unique $Q^{\prime\prime}$ such that $C:Q\to Q^{\prime\prime}\cup Q^{\prime}$ and $\emptyset;Q^{\prime\prime}\vdash M:A$ . Then

[TABLE]

Proposition 5.6 (Soundness).

If $Q\vdash(C,M):A;Q^{\prime}$ is a well-typed configuration and $(C,M)\Downarrow(C^{\prime},V)$ , then $[[(C,M)]]=[[(C^{\prime},V)]]:[[Q]]\to[[A]]\otimes[[Q^{\prime}]]$ .

The soundness property implies that the operational semantics coincides with the categorical semantics. An important special case arises if we have a closed term $M:{\rm Circ}(T,U)$ . The categorical meaning of $M$ is some generalized circuit $[[M]]:[[T]]\to[[U]]$ . Operationally, the term $M$ evaluates to some boxed circuit $(\vec{\ell},D,\vec{\ell}^{\prime})$ , and soundness ensures that $[[M]]=[[(\vec{\ell},D,\vec{\ell}^{\prime})]]$ . Therefore, at observable types such as ${\rm Circ}(T,U)$ , our evaluation rules are a constructive implementation of the categorical semantics. More generally, we have the following adequacy property.

Proposition 5.7 (Computational adequacy).

If $\emptyset\vdash(C,M):A;\emptyset$ such that $[[(C,M)]]=[[(C^{\prime},V)]]$ and $A$ is an observable type, then $(C,M)\Downarrow(C^{\prime},V)$ (possibly up to a renaming of labels in $V$ ).

As promised in Remark 3.2, the proofs of the soundness and adequacy properties are independent of the choice of the category $\overline{\bf M}$ . This justifies not having made such a choice in the first place.

6 Conclusions and future work

We systematically constructed a programming language for describing families of generalized circuits by first giving a categorical model and then defining the language to fit the model. The language has an operational semantics, and we proved safety, soundness, and adequacy properties showing that the computational and categorical meanings coincide.

A software implementation of Proto-Quipper-M is in progress and almost completed. In future work, we hope to extend the language to encompass successively larger sets of features of the original Quipper. For example, the current version of Proto-Quipper-M lacks a general recursion scheme, so that all programs are terminating (see Proposition 5.4). Adding recursion to the programming language is no problem at all, but how to add it to the categorical model while preserving soundness and adequacy is an open question.

Another question we hope to address in future work is the exact relationship between Proto-Quipper-M and the version of Proto-Quipper from Ross’s thesis [10]. While these two languages have much in common, they differ in some important aspects: for example, Ross’s Proto-Quipper uses a subtyping relation ${!}A\mathrel{<:}A$ instead of explicit “ $\mathop{\rm lift\,}\nolimits$ ” and “ $\mathop{\rm force\,}\nolimits$ ” operators. This is convenient for programmers, but giving a categorical semantics for Ross’s version of Proto-Quipper is left for future work.

7 Acknowledgements

This work was supported by the Natural Sciences and Engineering Research Council of Canada (NSERC) and by the Air Force Office of Scientific Research, Air Force Material Command, USAF under Award No. FA9550-15-1-0331. This work was done in part while the authors were visiting the Simons Institute for the Theory of Computing.

Bibliography11

The reference list from the paper itself. Each links out to its DOI / PubMed record.

1[1]
2[2] Nick Benton (1995): A Mixed Linear and Non-Linear Logic: Proofs, Terms and Models (Extended Abstract) . In: Proceedings of the 8th Workshop on Computer Science Logic, CSL’94, Selected Papers , Springer Lecture Notes in Computer Science 933, pp. 121–135, 10.1007/B Fb 0022251 . · doi ↗
3[3] Brian Day (1970): On Closed Categories of Functors . In: Reports of the Midwest Category Seminar IV , Lecture Notes in Mathematics 137, Springer, pp. 1–38, 10.1007/B Fb 0060438 . · doi ↗
4[4] Alexander Green, Peter Le Fanu Lumsdaine, Neil J. Ross, Peter Selinger & Benoît Valiron (2013): Quipper: a Scalable Quantum Programming Language . In: Proceedings of the 34th Annual ACM SIGPLAN Conference on Programming Language Design and Implementation, PLDI 2013, Seattle , ACM SIGPLAN Notices 48(6), pp. 333–342, 10.1145/2499370.2462177 . Also available from http://arxiv.org/abs/1304.3390 . · doi ↗
5[5] Alexander Green, Peter Le Fanu Lumsdaine, Neil J. Ross, Peter Selinger & Benoît Valiron (2013): The Quipper language . Software implementation, available from http://www.mathstat.dal.ca/~selinger/quipper/ .
6[6] Gilles Kahn (1987): Natural Semantics . In: Proceedings of the 4th Annual Symposium on Theoretical Aspects of Computer Science (STACS 1987) , Springer, pp. 22–39, 10.1007/B Fb 0039592 . · doi ↗
7[7] S. Mac Lane (1998): Categories for the Working Mathematician , 2nd edition. Graduate Texts in Mathematics, Springer, 10.1007/978-1-4757-4721-8 . · doi ↗
8[8] Paul-André Melliès (2009): Categorical semantics of linear logic . In: Interactive Models of Computation and Program Behaviour , Panoramas et Synthèses 27, Société Mathématique de France, pp. 1–196.

TL;DR

Contribution

Findings

Abstract

Peer Reviews

Videos

A Categorical Model for a Quantum Circuit

Abstract

1 Introduction

2 A cartesian model of parameters and state

2.1 The model Set2op{\bf Set}^{{\bf 2}^{\it op}}Set2op

Definition 2.1**.**

Example 2.2**.**

2.2 A lambda calculus for parameters and state

3 A categorical model of circuit families

3.1 The category M{\bf M}M: generalized circuits

Remark 3.1**.**

3.2 The category M‾\overline{\bf M}M: state

Remark 3.2**.**

3.3 The category M‾‾\overline{\overline{\bf M}}M: parameters

Definition 3.3**.**

Proposition 3.4**.**

Proposition 3.5**.**

3.4 Properties of objects

3.5 Some basic types and operations

3.6 Inductive types

3.7 Boxing

Proposition 3.6**.**

Definition 3.7**.**

Remark 3.8**.**

Remark 3.9**.**

Theorem 3.10**.**

3.8 Meta-operations on circuits

4 Towards a circuit description language

4.1 Overview

Remark 4.1**.**

4.2 Labelled circuits

Definition 4.2** (Labelled circuits).**

Remark 4.3**.**

4.3 The syntax of Proto-Quipper-M

4.4 Categorical semantics

5 Operational semantics

5.1 Evaluation rules

5.2 Safety properties

Definition 5.1**.**

Proposition 5.2** (Subject reduction).**

Proposition 5.3** (Error freeness).**

Proposition 5.4** (Termination).**

5.3 Soundness properties

Definition 5.5**.**

Proposition 5.6** (Soundness).**

Proposition 5.7** (Computational adequacy).**

6 Conclusions and future work

7 Acknowledgements

2.1 The model ${\bf Set}^{{\bf 2}^{\it op}}$

Definition 2.1.

Example 2.2.

3.1 The category ${\bf M}$ : generalized circuits

Remark 3.1.

3.2 The category $\overline{\bf M}$ : state

Remark 3.2.

3.3 The category $\overline{\overline{\bf M}}$ : parameters

Definition 3.3.

Proposition 3.4.

Proposition 3.5.

Proposition 3.6.

Definition 3.7.

Remark 3.8.

Remark 3.9.

Theorem 3.10.

Remark 4.1.

Definition 4.2 (Labelled circuits).

Remark 4.3.

Definition 5.1.

Proposition 5.2 (Subject reduction).

Proposition 5.3 (Error freeness).

Proposition 5.4 (Termination).

Definition 5.5.

Proposition 5.6 (Soundness).

Proposition 5.7 (Computational adequacy).