# On the Definition of Quantum Programming Modules
## 4 Discussion  
For a successful achievement of a quantum software engineering discipline, we considered crucial the establishment of abstractions for quantum software development. In  
Figure 10: (**a**) A sample of a circuit embedding a module with communicational cohesion. (**b**) The implementation of the module including OR/AND submodules. The tasks performed within the module (AND/OR operations) share the first three incoming qubits as input data. (**c**) Detail of the implementation of the submodules. object-oriented software development, as an evolution from the original abstract data types, the main abstractions used were the concepts of object and classes, as factories for creating objects according to a given template. Before that, procedures and functions were the only abstractions available to implement software, defined as a sequence of instructions that manipulate (common) data, and allowing hierarchical interactions through procedure-to-procedure calls. At first sight, the notion of class may not be probably an adequate abstraction for quantum software development. The software engineering community may have the temptation to quickly adopt well-known abstractions (classes, objects, etc.) and their corresponding techniques and look for the equivalence for developing quantum software, trying to do something that is radically different. As stated in [31], researchers should focus their contributions having in mind to \"think and model in quantum\". This is exactly the rationale behind the seven rules that define a module that have been described in this work. We think that they are the minimum set of rules necessary to allow the successful creation of modules in quantum programming. However, they can nevertheless be extended with additional ones by quantum software designers according to their specific needs and limitations (for instance, characteristics of the hardware where they execute their QP). The rule #1 states that the elementary quantum gates are modules, while #6 says that all groupings of gates that meet the previous rules are also modules. That is, they are the rules that establish that it is possible to create new modules by composing modules that meet certain properties. These types of rules are present in the definition of reusable entities in all classical programming languages. Rules #2 to #5 are derived from the intrinsic characteristics and limitations imposed by quantum mechanics as follows. Rules #2 and #3 are directly related to the fact that computation must be unitary and reversible. If additional qubits are used to store temporary results (ancilla qubits), they must be restored to the previous state after performing the computation before being used in a new computation to avoid unwanted effects of their (possible) entanglement with other qubits. Rule #4 is, perhaps, the most surprising one, derived from deeper research on modularity of quantum circuits. It states that a set of gates and sub-modules can be considered modular, and therefore, can be reused as a building block in other QP only if its black box properties, that is, considering only the input and output values, do not allow the user of the module to identify how it is implemented. From this it follows that, unlike classical programming languages, not every grouping of quantum gates is modular per se. Rule #5 only applies if, in a module, it is needed to include control-U functionality. That is, if one or more qubits are going to control whether a certain part of the module, which implements a U operation, should be executed or not. As such, this rule is not essential since many algorithms do not need to make use of this functionality. However, if needed, it should be included carefully, for instance, by using SWAP gates. Rule #7 states that, if any entangled qubit enters a module, then all the qubits that are entangled with it must enter the module too.