Locus: A Proposal for Quantum Software Composition

The development of quantum computers in recent years has fostered the emergence of the discipline of Quantum Software Engineering (QSE) [12]. This discipline addresses the special requirements of quantum software in contrast to classical software, providing appropriate engineering processes for building quantum programs [8].

Many features of quantum systems make the constructs of classical programming languages inadequate for programming them. Some of these include dealing with a machine state that incorporates superposition, the fact that information units (qubits) can be manipulated in dimensions of phase and amplitude, the collapse of the qubits’ superposition state when measured, and the impossibility of replicating all or part of the quantum state once it has been measured. The mechanisms provided by quantum programming languages to handle these characteristics build on quantum gates that can be applied to one or multiple qubits.

These mechanisms are similar to those found in the assembly language of a classical processor, where operations are performed on a bit or register [8]. As a result, building quantum programs nowadays is not only a tedious task but also, much like assembly routines, leads to very poor results in terms of reusability, maintainability, and compositionality.

The aim of this work is to contribute a new abstraction for quantum programming languages, designed to facilitate the creation of quantum programs as a composition of operations implemented as circuits. The proposed abstraction is called Locus (from the Latin for “place”), and it defines a place in the quantum program specified by a set of qubits and the operations that have been applied to those qubits up to that point. In this way, a Locus represents the quantum sub-state determined by the state of its associated qubits at the moment it is created. The purpose of defining a Locus is to apply an operation to it. This operation is simply a quantum circuit applied to the qubits of the Locus, that is aimed to produce a specific transformation.

The concept of a Locus may resemble that of a variable in a classical program, which defines part of the machine’s state on which operations (appropriate to the variable’s type) are to be applied. However, it differs in that two Locus instances over the same qubits, but at different points in the program, are considered two distinct Locuses. The specific operation to be applied to a Locus can be determined at a later stage or delegated to another part of the program. In this sense, applying an operation to a Locus can be regarded as a form of dependency injection into the Locus. The benefits it provides are analogous to those of this mechanism in classical programming: decoupling of code, which facilitates reusability and maintainability, as well as support for patterns such as inversion of control. To illustrate these aspects, the abstraction has been implemented in Qiskit, and several usage examples are provided in the paper.

This paper is structured as follows. Section 2 describes the motivation for this project. The following Section 3 explains the concept we propose in the article: Locus. This section will be divided into two subsections: 3.1 will describe the notion and use of Locus and subsection 3.2 will present some examples. Section 4 includes a discussion and related works. Finally Section 5 concludes the article with some conclusions.

The principle of separation of concerns (SoC) introduced by Dijkstra [2] is ubiquitous in classical software development.

The proven effectiveness of this principle in classical software development suggests that it should be adapted for quantum software development. We can already identify opportunities to apply this design principle in many examples of quantum algorithms. For instance, Grover’s search algorithm [5] consists of an alternation between two operations: the oracle and the diffusion operator. These two operations can be identified as separate modules.

Two further examples are Shor’s algorithm [10], which employs the Quantum Fourier Transform (QFT) [1] internally as a standalone module – and the Quantum Approximate Optimization Algorithm (QAOA) [3], which is built from successive layers, each containing a problem-dependent module, $U_P$, and another, $U_M$, that depends on the so-called mixing Hamiltonian (see Fig. 1).

The standardized mechanisms currently provided by quantum programming languages are those related to the sets of supported quantum gates. These are operations that manipulate single qubits (by applying a phase along any axis) or qubit registers (by creating entanglement among the qubits in the register). These types of instructions are very low-level and comparable to the instructions found in classical assembly languages for each processor. To provide programmers with higher abstraction mechanisms, some languages such as Qiskit¹¹1We take Qiskit as a reference since it supports advanced abstractions and it is the most widely used quantum programming language. [7] offer builder operations such as Custom Gates. A custom gate allows us to encapsulate functionality in modules that can be applied and reused in different programs. It is, in fact, a powerful abstraction mechanism that should not be confused with a simple gate. A custom gate can be parameterized in terms of the qubits it involves, and even in the structure of the internal circuit it implements.

For a custom gate to be reusable, it must be well-designed [9]. For example, a custom gate that implements a generic QFT can be created. The QFT can then be reused in various programs requiring this functionality, such as an implementation of Shor’s algorithm. To enable that reuse, the QFT must be parameterized with the number of qubits in the circuit implementing the QFT. This prevents the need to build QFT custom gates for different circuit sizes. Such parameters allow to adjust how the circuit implementing the custom gate is constructed. The custom gate mechanism is complemented by the ability to specify, at instantiation time, how the qubits of the custom gate are connected to those of the receiving circuit.

In this way, custom gates are a mechanism that gives the programmer the freedom to create their own levels of abstraction in the form of complex operations. At the same time, they allow for the construction of reusable quantum code libraries. However, they still encourage building programs in a sequential manner. Gates and the different parts of the circuit are composed (using the append instruction) one after another. Once a custom gate is added to a circuit, its function and the way it connects to the circuit become fixed. As a result, common practices in classical programming – such as expressing conditional or deferred behavior – become difficult to implement. To address this gap, the next section introduces the Locus mechanism, a placeholder in the circuit where functionality will be added later. Locus can be used as a complement of custom gates.

In this section we will discuss the Locus concept we present as well as an early phase of the implementation of the concept by showing some examples.

The Locus concept is intended to provide programmers with the ability to conceive their quantum applications as a composition of modules. The goal is to enable the construction of quantum applications using a top-down approach, shifting across different levels of abstraction beyond that of quantum gates. In addition to its use in quantum programming languages, Locus can also be adopted in higher-level representations of quantum applications, such as Architecture Description Languages (ADLs) or modeling languages.

Some current quantum programming languages also offer abstractions beyond quantum gates. Perhaps the most well-known are those found in Qiskit, such as Registers and Custom Gates. These abstractions, when used together, are powerful and enable basic composition mechanisms. Although custom gates are primarily designed to encapsulate the implementation details of a circuit segment, they can also be used to abstract the connections between different parts of a quantum program. If such parts are also provided as quantum gates, it is possible to compose complex quantum programs as combinations of custom gates, with the composition itself supported by the custom gate mechanism.

The idea of creating reusable quantum code can be found in other proposals, such as the one by Guo et al. [6]. In this work, ansatzes are mentioned as methods of designing and creating quantum algorithms. Its main contribution is to assist quantum algorithm designers by offering a structured repository of design patterns that enable the selection and reuse of ansatzes for variational quantum algorithms. Our Locus proposal can extend this work by introducing a new abstraction level that complements ansatz selection. While Guo et al. focus on the structure of the circuit, Locus focuses on how to organize, compose, and inject these structures in a flexible and maintainable manner. Locus enables deferred circuit injection, separation of concerns, and modularity promoting reuse and adaptability, which align closely with the reuse and abstraction goals emphasized by Guo et al.. Conversely, the ansatz catalog can directly enhance the Locus concept by serving as a structured repository of candidate modules to inject.

Another related proposal is by Fernández-Osuna et al. [4]. They provide a large-scale analysis of how foundational quantum design patterns, such as initialization, superposition, entanglement, and oracle, are used in practice across Qiskit-based quantum programs. Our Locus proposal aligns naturally with these goals by introducing a higher-order abstraction for composing quantum operations. Locus provide support for the implementation of the architectural patterns so the instantitation of the different components can be deferred by injection. This compositional mechanism thus complements existing patterns by offering a flexible framework to structure and integrate them in scalable quantum software.

Also, [11] introduces high-level quantum data types into the Rhyme language to simplify quantum programming. These types extend classical primitives such as integers, floats and strings to the quantum domain, allowing developers to express superposition and entanglement using the familiar classical function syntax. While Rhyme abstracts typed quantum variables, Locus instantiated in the qbits correponding to a variable provide support for injecting the implementation of the different operations over the variable. structures how and where these operations are composed and injected into the circuit.

Finally, as shown in the examples, Locus can be used in conjunction with custom gates. In fact, Locus does not add any new functionality. Everything that can currently be done with Locus can also be achieved using registers and quantum gates. The difference lies in the approach: while registers and gates encourage building the application as a sequence of circuits that are appended to the existing one, Locus promotes thinking in terms of distinct functionalities that will be composed within a defined structure. Thus, custom gates are primarily conceived to encapsulate implementations within a circuit, whereas Locus is intended for broader use cases, including higher-level structural composition. Moreover, Locus allows deferring the implementation of some of these functionalities to a moment after their instantiation.

In this work, we have presented Locus, a mechanism that helps quantum application programmers approach development following a top-down methodology. Using this approach, they can generate multiple levels of abstraction between which they can shift. The concept of Locus is currently implemented as a prototype through additional syntax in Qiskit.

Locus facilitates deferring and delegating the implementation of application functionalities. However, all contextual conditions that may be evaluated to decide when and how a functionality is implemented belong to the (classical) Qiskit program that builds the quantum circuit. Ideally, a more powerful mechanism would be desirable, for instance, defining the circuit to be executed based on the result of measuring part of the quantum state. This can be done in Qiskit using IfElseOp, a mechanism that is mostly used for error mitigation. Even when the use of IfElseOp and WhileLoopOp operations imposes some limitations, exploring the possibilites of using them in conjuntion with Locus opens many possibilities for building complex dynamic and reactive quantum programs. As future work, we are already working on putting together all this concepts.