# On the Definition of Quantum Programming Modules
## 4 Discussion
This is a recommendation, rather than an obligation, considering that we aim to achieve universal module reuse, that is, being able to reuse the module without knowing anything about the rest of the quantum program in which it will be integrated into. The objective is to mimic the characteristics of the standard libraries that come with programming languages, like <math>, which provide functionality that can be used and reused many times, and which introduce no restrictions or assumptions about the source code that surrounds their use. Entanglement opens up the possibility that qubits entering a module are modified by some other parts of the quantum program, outside the module's control. It is like having global variables or pointers to the local variables of functions, which can be modified from any point of the source code, in a concurrent program. This is, in general, a bad design. If the programmer is careful, one can still create a program that does its job and uses global variables, since one knows and controls how the code is implemented. However, it would be hard and error-proneto reuse these functions in other programs, especially by third parties. Our position with entanglement is similar to this one, and this is why we state that, in order to maximize reuse, all entangled qubits or none at all should enter a module. This rule may seem too restrictive but, from our point of view, is needed if we want to converge to an off-the-shelf scheme of module cataloguing and reuse in quantum programming. We have also purposely avoided, in general, references to concrete quantum programming languages when defining the main properties that a module should have. Our objective is to provide a \"language-agnostic\" module definition, which could be used in any such language, given the variability in their implementation (from imperative languages like Q#, functional languages like QPL to specialized libraries and SDKs for general-purpose languages like Qiskit). We adapted the classical definitions of cohesion and coupling between modules to the characteristics of the (circuit-based) quantum programming and quantum modules. The different levels of cohesion highly determine the coupling level between the modules. As expected, the higher the cohesion, the lower the coupling, which provides much better reuse, among other benefits from modular design. The provided classification can be subjected to other points of view and updates, given the novelty of quantum programming and the small quantity of examples to take as input to evaluate it. For instance, since there is no support for datatype definitions right now (data are just qubits) it makes no sense to consider stamp coupling. However, this may change in the future. Further, most of the developed algorithms were designed for a specific task and they are not usually conceived thinking in their reuse as part of a more general program. As the development of new software and algorithms for quantum programming progresses, new case studies become available to validate the usefulness of heuristics such as those provided in this work. On the other hand, we identified a new type of coupling that is only present in QP: coupling by entanglement. We also made a proposal for a general internal structure that a module could have, according to the module definition rules described in the article. Not all the blocks proposed on the structure are mandatory, but rather the objective is to provide a starting point, it is, a template for helping the quantum module designer to keep in mind all the options that he should consider when developing quantum modules. As with general purpose languages where the use of generics is important, the parameterization of modules in such a way that concrete realizations can be made from a template is also of interest.