Quantum Programming Languages

1.1 Language Families

Suppose we want a computer to prepare the Bell state \((\ket{00}+\ket{11})/\sqrt2\). We know the circuit. How many genuinely different ways are there to write it down for a machine? We first compare two ways of organizing the instructions, and then ask who reads the resulting text.

1.1.1 Imperative and functional approaches

The most direct attempt copies the circuit drawing from left to right. We name the qubits and list the actions in time order:

qubits q0, q1, both starting in |0⟩
apply H to q0
apply CNOT with control q0 and target q1

This is an imperative description: a sequence of commands that change named things, one after another.

We could instead describe the same computation as one transformation built from smaller ones. The two-qubit operation is \(\mathrm{CNOT}\,(H\otimes I)\), and the program is that product applied to \(\ket{00}\). This is a functional description: it says what the result is, as a composition of transformations, rather than listing changes in order.

Does the choice of style change the state we get? It cannot, because both describe the same matrix product. Let us check it. \(H\) on the first qubit gives \((\ket{00}+\ket{10})/\sqrt2\), where the first label is q0. CNOT then flips q1 exactly when q0 is 1, giving \((\ket{00}+\ket{11})/\sqrt2\).

So the styles differ only in what they make easy to see. The imperative list looks like the drawing. The functional product makes composition visible. For example, the inverse of a product of unitaries is the product of their adjoints in reverse order, \((H\otimes I)\,\mathrm{CNOT}\), and a language that stores the product can build that inverse for us.

1.1.2 Standalone languages and embedded frameworks

Whichever style we choose, some program must read the text. Who? One answer is to invent a new language with its own grammar and its own compiler, the program that translates the text into instructions for a machine. That is a standalone language. Here is the Bell preparation, followed by measurement, in OpenQASM 3, a standalone language for circuits:

OPENQASM 3.0;
include "stdgates.inc";
qubit[2] q;
bit[2] c;
h q[0];
cx q[0], q[1];
c = measure q;

Each line declares two qubits, declares two classical bits, applies a gate, or measures. Q# is another standalone language, built around operations that can be composed and inverted.

A second answer reuses an existing language, such as Python, and adds a library of quantum objects to it. The existing language is then called the host, and the result is an embedded framework. Qiskit is such a framework: it is a Python software development kit (SDK), not a separate language. We gain everything the host offers, such as loops, functions and files, without writing a new compiler.

What do we pay for that? The host runs on our ordinary computer while it builds the circuit. Suppose we write, in Python, “repeat three times: append H to qubit 0.” The loop runs once, on our laptop, and leaves behind a circuit with three separate H instructions. The quantum device never sees a loop. So in an embedded framework we must keep two moments apart: construction time, when the host builds the circuit, and execution time, when the circuit runs.

1.2 Design Principles

So far the styles differ only on the surface. But a classical language also lets us copy a variable, reuse it freely, undo any step we like, and branch on any value. Which of these freedoms survive when the values are qubits? We test copying first, then undoing and branching, and each failure becomes a rule a quantum language should enforce.

1.2.1 Types, ownership, and no-cloning

In a classical program, writing y = x gives us a copy of the value in x. What should q2 = q1 mean when q1 is a qubit?

Suppose it meant “copy the state.” Then some unitary \(U\) would send \(\ket\psi\ket0\) to \(\ket\psi\ket\psi\) for every \(\psi\). On the basis states this forces \(U\ket0\ket0=\ket{00}\) and \(U\ket1\ket0=\ket{11}\). Since \(U\) is linear, \(U\ket+\ket0\) must then be \((\ket{00}+\ket{11})/\sqrt2\). A copy of \(\ket+\) would be \(\ket+\ket+=(\ket{00}+\ket{01}+\ket{10}+\ket{11})/2\), which is a different state. So no such \(U\) exists. This is the no-cloning theorem.

So q2 can only be a second name for the same qubit. A name that refers to a qubit without containing its state is called a handle. Assigning a handle copies the reference, never the quantum state.

Handles bring a new hazard. Suppose we write cx(q, q), a CNOT whose control and target are the same qubit. A CNOT acts on two distinct systems, so this instruction has no meaning. A language can reject it with a type rule, a rule about how values may be used that is checked before the program runs. A linear rule requires each qubit value to be used exactly once. An affine rule requires it to be used at most once, so a qubit may also be discarded. The quantum lambda calculus of Selinger and Valiron is built on a linear rule.

Qiskit enforces neither rule. It refuses a gate whose two arguments name the same qubit, but only when we try to append it. No-cloning still holds physically whether or not the language checks for it.

1.2.2 Reversibility, measurement, and classical control

Next, undoing. A routine built from unitaries \(U_1,\dots,U_k\) has the inverse \(U_1^\dagger\cdots U_k^\dagger\), so a language can generate it automatically, as in our functional description. Does this work for every routine?

Take a reset, which sets a qubit to \(\ket0\). It sends \(\ket0\) to \(\ket0\) and also \(\ket1\) to \(\ket0\). After it, nothing tells us which input we had, so no operation can undo it. A measurement whose result we throw away loses information in the same way. So only the unitary parts of a program have automatic inverses.

Now branching. A measurement produces a classical bit, and we often want a later gate to depend on it. Could we write an ordinary host-language if: “if qubit 0 is 1, apply X to qubit 1”? At construction time no measurement has happened yet. The host is only building a description, so there is no bit to test. The condition must therefore be an instruction inside the circuit that names a recorded bit. The controller evaluates it during execution, when the bit exists. This is called classical control.

1.3 Abstraction and Execution

We now have a description that a language can check. Two questions remain before we can run it. Real devices do not all offer the same gates, so how can one description serve many machines? And what does the description look like in Qiskit? Answering the first separates meaning from realization, and the second gives us our first program.

1.3.1 Circuit languages and intermediate representations

Our Bell description uses H and CNOT. Suppose a device can apply only a few kinds of rotation and one particular two-qubit gate. The operations a device implements directly are its native gates. Suppose also that each qubit can interact only with certain neighbours. Who turns our description into something this device can run?

A compiler does, and to rewrite a circuit safely it must know which operations act on which qubits and which must happen before which. A form of the program that records exactly this is called an intermediate representation. The compiler can replace each H by native rotations that agree with it up to a global phase. If two qubits that need a CNOT are not neighbours, it can insert swaps that move their states next to each other. That step is called routing.

After such rewriting the gate list looks different, yet the program means the same computation. So a language should keep two things apart: the circuit’s mathematical meaning, and its device-specific realization. Standalone circuit languages such as OpenQASM also serve as an exchange format between tools. Writing a circuit out in that format does not make every destination able to run it, since a device may lack, for example, classical control during execution.

1.3.2 Qiskit as a Python SDK

Qiskit has no grammar of its own. So what does our Bell preparation look like when Python is the host? We read the program below a few lines at a time. It uses only a handful of Python features, and each one is there because the program needs it.

Python starts with a small core. The from … import … lines borrow two definitions from the installed Qiskit package: QuantumCircuit, which describes circuits, and Statevector, which computes amplitudes. Lines beginning with # are comments for human readers.

We want a recipe we can reuse, so we package it as a function. The line def bell(): starts a function named bell. The indented lines below it form its body. Inside, circuit = QuantumCircuit(2) creates an empty circuit on qubits 0 and 1, and the equals sign gives it the name circuit. The dot in circuit.h(0) calls a method, an operation that belongs to that object. Here it appends H on qubit 0, and circuit.cx(0, 1) appends a CNOT with control 0 and target 1. Finally return circuit hands the finished circuit back.

The line circuit = bell() runs the recipe. Notice what it produces: a description, not a quantum run. What should that description contain? Before running anything we predict the amplitudes of \(\ket{00},\ket{01},\ket{10},\ket{11}\): \((1/\sqrt2,0,0,1/\sqrt2)\). In Python, 2**-0.5 is \(2^{-1/2}=1/\sqrt2\).

Statevector.from_instruction(circuit) computes the amplitudes of the circuit’s output by an ordinary classical calculation. The method equiv compares that state with our prediction, ignoring any global phase. The word assert turns the comparison into a check. If the claim is true, nothing happens; if it is false, Python stops with an error. So a silent run means the prediction held. The last line prints a text drawing of the circuit.

"""Runnable companion for Quantum Programming, Chapter 1."""
from qiskit import QuantumCircuit
from qiskit.quantum_info import Statevector

# A Python function builds a circuit; it does not execute a quantum device.
def bell():
    circuit = QuantumCircuit(2)
    circuit.h(0)
    circuit.cx(0, 1)
    return circuit

circuit = bell()
assert Statevector.from_instruction(circuit).equiv(
    Statevector([2**-0.5, 0, 0, 2**-0.5]))
print(circuit.draw(output="text"))

Companion script: chapter_01.py.

The program shows the two roles we separated. The function builds a description, and Statevector evaluates it on a classical computer. Neither step touches a quantum device.

Our program passed its check on this computer. Would it give the same result on someone else’s, with whatever versions of Python and Qiskit they happen to have installed?

Sources and further study: OpenQASM language specification; Selinger and Valiron, quantum lambda calculus.