✨ Support multiple functions

[denialhaag]

Currently, our builders and conversions can only handle a single function. To support more arbitrary programs, we should extend this. An initial implementation can be found in #1396.

Things to keep in mind include:

• The builders must have an API for creating programs with multiple functions.
• The conversions must handle programs with multiple functions.
• The modifiers must handle bodies that comprise only a function call (in addition to the respective yield operation) correctly.
• Trivial function calls should be canonicalized away (e.g., consider a function that applies two X gates to the same qubit). In particular, this should also happen if the function call is inside a modifier.

[DRovara]

• The builders must have an API for creating programs with multiple functions.

#1970 covers this for the QCOProgramBuilder

• The modifiers must handle bodies that comprise only a function call (in addition to the respective yield operation) correctly.

This should only work if the function is a unitary, right? I think we currently have no way of indicating unitary functions

• Trivial function calls should be canonicalized away (e.g., consider a function that applies two X gates to the same qubit). In particular, this should also happen if the function call is inside a modifier.

This sounds like it could be a two-step process:

1. a local cancelling transformation removes the redundant X gates
2. a simple clean-up sweep removes empty functions

[denialhaag]

#1970 covers this for the QCOProgramBuilder

Very nice! 😎

This should only work if the function is a unitary, right? I think we currently have no way of indicating unitary functions

Yeah, good points! #1225 initially proposed a dedicated box operation (basically, a typed version of func.func). We might have to look into this again. 🤔

This sounds like it could be a two-step process:

1. a local cancelling transformation removes the redundant X gates
2. a simple clean-up sweep removes empty functions

Agreed!

[DRovara]

Yeah, good points! #1225 initially proposed a dedicated box operation (basically, a typed version of func.func). We might have to look into this again. 🤔

An alternative would be to define a sort of "decorator" for func.func functions to indicate unitary functions. That way, we would not have two almost equal constructs that have to be handled separately.

[burgholzer]

Yeah, good points! #1225 initially proposed a dedicated box operation (basically, a typed version of func.func). We might have to look into this again. 🤔

An alternative would be to define a sort of "decorator" for func.func functions to indicate unitary functions. That way, we would not have two almost equal constructs that have to be handled separately.

i suppose a function attribute would be the right thing here.

[burgholzer]

I suppose this will be somewhat tackled by #2196 and a potential follow up