Classical programming languages such as C++, Haskell, and Java employ static typing to improve compilation efficiency and programmer productivity by checking and inferring program types at compile time and flagging potential issues early, well before execution. Qmod is one of the few industry-ready quantum programming languages that offer static typing capabilities, adapted to the distinctive aspects of quantum computation. This post provides a short overview of static typing in classical languages and then demonstrates its implementation in Qmod.

Static vs. Dynamic Typing

Programming languages divide program objects such as numbers, strings, and arrays into groups called types and define the set of operations that can be applied to the members of each type. In Python, for example, the value 1 belongs to the int type (we can also say that 1is an int), but the value [1, 2, 3, 4] is a list. While we can subtract two int values, Python does not support subtracting two list values. On the other hand, we can iterate over the elements of a list, but cannot iterate over an int. The following program shows what happens when we try to iterate over an integer value in Python:

def mult_all(angles, arr):
    for i in range(len(arr)):
        arr[i] *= angles[i]
if __name__ == "__main__":
    arr = [1, 2, 3, 4]
    mult_all(4, arr)  # ERROR

he function mult_all accepts two list inputs and multiplies their elements. However, we call it with an integer argument 4 instead of a list, resulting in the following error message upon running the program:

 arr[i] *= angles[i]
              ~~~~~~^^^
TypeError: 'int' object is not subscriptable

Since we provided 4 as an argument to the angles parameter, the Python interpreter raises a type error when we try to access its members as if it were a list. Although the error is descriptive, it fails to identify the bug's location: A few lines below, where we call mult_all with 4 instead of a list. This is because Python is dynamically-typed, so it assigns types to values only at runtime.

In Java, which is statically-typed, the compiler checks the types of the mult_all arguments and correctly raises a type error:

error: incompatible types: int cannot be converted to double[]
	mult_all(4, arr);
	         ^

The error is now raised at the right location and, because it is thrown at compile time, the user can (and is required to) fix it before actually running the program.

Static Typing in Qmod

Qmod requires the programmer to declare the types of function parameters and checks them at compile time. For example, we can code up a situation analogous to the mult_all example above with the Qmod function rx_all as follows:

@qfunc
def rx_all(angles: CArray[CReal], qarr: QArray[QBit]):
    repeat(qarr.len, lambda i: RX(angles[i], qarr[i]))


@qfunc
def main():
    qarr = QArray(length=4)
    allocate(qarr)
    rx_all(4, qarr)  # ERROR

The type of the angles parameter is CArray[CReal]: A classical array of real numbers. The Qmod compiler checks that the argument 4 matches this type, and because it doesn’t match, it raises the correct type error:

Argument '4' of type CInt is incompatible with parameter 'angles'
of type CArray[CReal]

In addition to type checking, the Qmod compiler performs advanced static checks based on the unique rules of quantum computation. For instance, it requires that variables used in the control condition remain constant in the control block:

@qfunc
def main(res: Output[QNum[4]]):
    allocate(res)
  
    qn = QNum(size=4)
    allocate(qn)
    hadamard_transform(qn)
  
    control(qn < 2, lambda: inplace_add(qn, res))  # OK, qn is constant
    control(qn < 2, lambda: inplace_add(1, qn)  # ERROR, qn is mutable

Similar to type errors, the Qmod compiler reports non-constant-control violations at compile time:

Variable 'qn', which is used in the 'control' condition, cannot be
used in a non-constant operation under the controlled block