Provide alternative to resource manager

[stevenheidel]

Looking through Grove it seems like there might be better abstractions for managing qubits. Right now the approach is very iterative: actions are inserted directly into an instruction group when qubits should be made live or dead.

My intuition is that this does not lend itself well to program analysis. If in the future we provide some sort of allocation based on the chip tomography this could be difficult to implement inline. Instead I would suggest a more functional approach that captures qubits at the beginning and end of the program and allows for them to be referred to locally when they're in scope.

Here's the partially fleshed out idea: introduce a QubitSet object. Your program would define input sets (like input qubits, ancilla qubits, etc.) and then a set of output qubits. Within an individual QubitSet you could reference qubits by their position (an 8 QubitSet could be referenced using the integers 0-7). Then when composing programs together PyQuil would have functions to match inputs and outputs and could automatically discard ancillas.

This would be somewhat similar to resource manager except that you don't need to do things like allocating and freeing or passing qubits around by reference everywhere.

Issues #76 and #124 are relevant here

[marcusps]

I like the idea of moving towards composable programs, but it seems like we are slowly specifying a higher level language for quantum algorithms, which is great, but (in my opinion) retrofitting that into PyQuil may not be the best way to go about it.

Since the (quantum) resource limitations are quite static, it also seems natural to build a framework that allows for static analysis before execution -- at which point everything is translated to Quil, with no high-level abstractions.

[stevenheidel]

@marcusps - I agree with the general sentiment here, talked with Johannes about this too. Sounds like we should keep PyQuil to be an almost 1:1 mapping with Quil: just a simpler way of writing quil instructions than writing them out by hand. Then we can build something on top of it which would be converted to quil by a compiler layer instead instead of retrofitting it into PyQuil. This way it could be used by programmers in any language who are writing Quil programs. Closing this issue since it sounds like we're all on the same page.