No more quantum and quantum_functional

[lmondada]

It is no secret, I have never liked having two functions for every gate type. But today is different -- I come with arguments and a concrete proposal that I hope you find convincing.

Argument

Most often, the borrowing signatures are most useful. However, there are cases where their functional equivalent would be nicer to use. I would much rather write:

@guppy
def plus_state() -> qubit:
     return h(qubit())

rather than

@guppy
def plus_state() -> qubit:
    q = qubit()
    h(q)
    return q

Starting to mix two functions for the same gate within my code is so ugly I would refuse to do so. But even discarding this subjective choice: using the two versions is not even an option for user-defined code: if I were to write my custom def my_hadamard, I would have to pick my poison and stick with it.

Concrete proposal

I propose to change the semantics of function definition and function calls in guppy as follows:

1. Every function is functional (i.e. we only keep quantum_functional)

2. However, we keep the current convention in the type signature: linear types have borrow-like semantics by default and must be tagged with @owned to take ownership.

3. When no linear resource is either created or destroyed, the return type can be easily inferred from the function arguments. In such cases specifying the return type and the return statement is optional (this is syntactic sugar). Specifically, an explicit return type and return statement are required if one of the following applies

   • A linear argument to the function is marked @owned
   • Ownership of a callee-created linear resource should be passed to the caller.

   Whenever none of these apply, the return type is inferred to be all linear typed arguments, in the same order.

4. We introduce the equivalent syntactic sugar also at the call site: whenever a function is called and both

   • the function is defined with an implicit return and
   • the outputs of the function are discarded

   are satisfied, we assign the output to the list of linear resources passed to the function.

5. Linear resources passed as function arguments not marked as @owned may not be discarded.

Advantages

• Support both functional and borrowed styles, as is the case currently.
• The borrowed style becomes more limited and is not supported on "complex" function types. This is IMO a feature, types such as def f(q: qubit) -> qubit are just plain confusing. Whenever linear resources are created or discarded, the user is encouraged to think and express explicitly where the resources go.
• These rules are unambiguous because they use the fact that linear types cannot be discarded implicitly. In all cases where syntactic sugar is introduced, any other interpretation of the code would be invalid.
• The type system is simplified: we do not need to introduce Rust-style borrowing and ownership concepts. Borrows can be recast as "syntactic sugar" and ownership as a tag "to consume a qubit".

Examples

@guppy
def cx(ctrl: qubit, target: qubit):
    ...

cx(q0, q1) # ok

# also ok:
def bell_state() -> (qubit, qubit):
    return cx(h(qubit()), qubit())

would be read as

@guppy
def cx(ctrl: qubit, target: qubit) -> (qubit, qubit):
    ...
    return (ctrl, target)

q0, q1 = cx(q0, q1)

def bell_state() -> (qubit, qubit):
    return cx(h(qubit()), qubit())

---

@guppy
def foo(qb: qubit): # implicit: -> qubit
    q = qubit()
    ...
    discard(q)
    # implicit: return qb

---

@guppy
def foo(qb: qubit):
    q = qubit()
    ... # no discard(q)
   # compiler error: you must either discard q or provide an explicit return statement

---

@guppy
def foo(qb: qubit) -> (qubit, qubit):
    q = qubit()
    ... # no discard(q)
   return (qb, q)  # ok; must be specified

foo(qb) # compiler error: this function has an explicit return, so outputs must be assigned explicitly: (qb, q) = foo(qb)

---

@guppy
def foo(qb: qubit @owned) -> qubit:
    return qubit()

foo(qb) # compiler error: this function has an explicit return, so outputs must be assigned explicitly: q = foo(qb)

---

@guppy
def foo(qb: qubit) -> (qubit, f64):
    # An explicit return type on a function that would have been eligible for implicit return    
    return (qb, 3.)

foo(qb) # compiler error: this function has an explicit return, so outputs must be assigned explicitly: q,  _ = foo(qb)

FAQ

Isn't @owned redundant?

It is true that @owned no longer changes the type of the argument -- this is the type simplification that is mentioned earlier. However, it signals the user's intention to consume the qubit. Concretely, it serves three purposes

• It forbids implicit returns
• It allows the callee to discard or measure the qubit
• It documents in the API that this qubit will (may) not be returned. The caller can otherwise assume her qubits are safe from destruction in function calls.

[mark-koch]

Thanks for this proposal, Luca! I'll have a deeper think about it later, here are some initial questions:

1. Moved arguments

How would you handle this function:

def foo(q: qubit):
   r = q
   h(r)

Or this one:

def foo(q1: qubit, q2: qubit, b: bool):
   if b:
      q1, q2 = q2, q1
   cx(q1, q2)

I assume this would require an explicit return? Current Guppy rejects the assignments since borrowed values cannot be moved.

2. Classical returns

Am I right in assuming that returning classical data from a function always requires an explicit return, threading through all linear inputs (see your last example)?

3. Infectious explicit returns

If (1) requires an explicit return, then it seems like explicity is "infectious": As soon as one function is explicit, all functions that call this function must be explicit as well:

def foo(q: qubit) -> (qubit, float):
   x: float = ... # Some classical computation
   return q, x  # Return must be explicit?

def bar(q: qubit) -> qubit:
   q, x = foo(q)  # Call must be explicit
   # Do something with `x`, then throw it away
   return q  # Now, bar also needs an explicit return :(

def baz(q: qubit) -> qubit:
   q = bar(q)  # Call must be explicit :(
   return q  # Return must be explicit :(

In current Guppy, taking ownership is infectious as well, but imo it's useful there since it tells us about the lifetime of qubits. Here, I don't see the benefit of baz having to thread the q argument through.

[lmondada]

Thanks for your comments and questions! Let me answer one by one:

1. Good point! Just one option among many, but to keep it simple: I would suggest that the implicit return is always exactly the same variables in the same order as the linear types in the parameter list. In this case, your second example would be valid, but for the first one, guppy would complain:

def foo(q: qubit):
   r = q
   h(r)
   # compiler complains: "q cannot be implicitly returned as it was moved"

2. Yes, that is the idea. The reason is that I am suggesting the simple rule: implicitly returned variables equals linear parameters, in the same order. If this does not apply, the user should specify exactly what they want.

3. No, explicity is not infectious. def bar(q: qubit) is eligible for implicit return as it satisfies the criteria (it does not discard a linear resource passed as parameter, nor does it return a newly created linear resource). Similarly, def baz(q) is also eligible.

Does this make sense? Thanks again for considering these ideas!

[mark-koch]

1. Good point! Just one option among many, but to keep it simple: I would suggest that the implicit return is always exactly the same variables in the same order as the linear types in the parameter list. In this case, your second example would be valid,

I feel like this would be quite confusing since it would effectively also swap the qubits in the calling scope, right? This would be unexpected for people that are used to Python's semantics

2. Yes, that is the idea. The reason is that I am suggesting the simple rule: implicitly returned variables equals linear parameters, in the same order. If this does not apply, the user should specify exactly what they want.

I would argue that in most situations like this, it's better to be implicit:

@guppy
def f(q1: qubit, q2: qubit @owned) -> int:
   entangle(q1, q2)
   b = measure(q1)
   # Do some post-processing
   return g(b)

@guppy
def main()
   q1, q2, q3 = qubit(), qubit(), qubit()
   sum = f(q1, q2) + f(q1, q3)
   discard(q1)

Imo it would almost never be useful to call the functional version of a function like f. By keeping the qubit threading implicit, it's easier to process the classical results. Otherwise, you'd have to do

x1, q1 = f(q1, q2)
x2, q1 = f(q1, q3)
sum = x1 + x2

This is essentially the same argument you used for why you prefer h(qubit()).

3. No, explicity is not infectious.

I see, I misread that bit in your proposal 👍 I agree that you avoid this problem by implicitly returning arguments "by name", i.e. return whatever is currently bound to the name of the argument. But it makes me uncomfortable that this violates Python's semantics where assigning to a local variable shouldn't affect the calling scope.

[lmondada]

Good points, I agree with the issues you are raising, i.e.

1. introducing a swap with q1, q2 = q2, q1 is not Pythonic, and that makes "return by name" problematic
2. returning qubits clutters the return type of function returning other data

I will think a bit more about this and see if I can address these concerns. I still hope there is a way to reconcile both.

[mark-koch]

Regarding the other points you made, I don't fully agree with

The type system is simplified: we do not need to introduce Rust-style borrowing and ownership concepts. Borrows can be recast as "syntactic sugar" and ownership as a tag "to consume a qubit".

The current system can also very easily be understood as syntactic sugar: Every function implicitly returns all linear arguments that are not @owned. Evey call implicitly assigns these returns back to the passed variables. I'd argue this syntactic transformation is actually easier to explain than the one in your proposal. In my opinion, framing this in terms of ownership and borrowing is more natural and users should think about it this way, but if people disagree, we can go back to the syntax sugar explanation.

Starting to mix two functions for the same gate within my code is so ugly I would refuse to do so.

Hmm would it be that bad to do

import guppylang.std.quantum_functional as F

def plus_state() -> qubit:
     return F.h(qubit())

This is a common pattern in e.g. pytorch.

using the two versions is not even an option for user-defined code: if I were to write my custom def my_hadamard, I would have to pick my poison and stick with it.

That's a fair point though!

[lmondada]

The current system can also very easily be understood as syntactic sugar: Every function implicitly returns all linear arguments that are not @owned. Evey call implicitly assigns these returns back to the passed variables. I'd argue this syntactic transformation is actually easier to explain than the one in your proposal. In my opinion, framing this in terms of ownership and borrowing is more natural and users should think about it this way, but if people disagree, we can go back to the syntax sugar explanation.

Viewed this way, I think my proposal does not change the semantics of @owned—it's the same thing as what you say. I've added constraints on when this syntactic sugar gets applied (e.g. when some of the argument qubits are @owned), with the reasoning that the user should explicitly state the order in which the resources should be returned when the exact same order as the parameter ordering isn't possible. This can be discussed and made as lenient as it is right now in guppy if we wanted.

My proposal changes two things

• this syntactic sugar is explicitly forbidden in cases where it could be confusing. E.g. cases that both take qubit references and return newly allocated qubit()s. An admittedly pathological case, that is valid guppy today:

@guppy
def wrong_h(q: qubit) -> qubit:
    q2 = qubit()
    h(q2)
    return q2

q = qubit()
qq = wrong_h(q) # Now this looks like a functional call...
# ...but in fact we now have two qubits alive

• at the call site, for functions that are eligible for the syntactic sugar, the caller can opt for either the explicitly functional or the implicit "by-reference" call.

I claim that because only a restricted subset of functions may use the implicit return call style, it is never ambiguous or confusing what the program does.

[lmondada]

Related thought: the by-reference semantics aren't quite syntactic sugar right now, as they force the caller to use a by-reference call, i.e. there is no desugared version of the call to a by-reference function.

Viewed this way, this whole proposal is just about accepting the desugared form as valid guppy.