Use case / style guide: writing programs is like cooking 🍰

[jon-wurtz]

Yesterday, we had an internal QuEra hackathon to explore building, analyzing, and running programs using bloqade-circuits. Some of @MilanKornjacaQ's comments, in particular, got me thinking. Mainly two things:
A) The typical quantum user/programmer should (rightfully) not care about SSA and the particulars of compiler passes but nonetheless wants finer control over the compiler's action beyond monolithic lowering. I had a lot of trouble trying to understand how to write my own compiler pass, which corroborates this point.
B) Once the kernel is made, its internals are very opaque in terms of analysis and difficult to modify beyond the composition of kernels. @stefan-o found it odd that lowering happens in-place, and @plquera had trouble trying to analyze the program to find the CZ gate count.

These two observations bring up a broader use case and requirement: ensuring that once a kernel has been made, it can easily be manipulated, analyzed, and understood without needing to (and without being restricted by!) relying on the underlying SSA.

This brings me to an analogy as to how we might be able to have users meaningfully engage and interact with bloqade. Hear me out: what if writing a quantum program was like cooking?

When you're baking a cake, you don't just dump all the ingredients together and shove it in the oven. You sift the flour and mix the dry ingredients together. You use different bowls to compose different ingredients with different processes; the eggs get scrambled in with vanilla, the buttercream frosting is whipped in a blender and dolloped on by hand on the cake after it is baked/transformed/lowered in the oven. In the end, the final product of a slice of cake on a plate is the result of many heterogeneous processes being applied to many compositions of different ingredients and mixtures.

Perhaps we can apply a similar vision to building bloqade programs. Individual ingredients are analogously hand-written kernels or stdlibs. Mixing ingredients together might be a composition of kernels into new kernels, or specific utility functions/stdlibs that generate new (ensembles of) kernels. Cooking/baking/mixing/transforming are analogously transformations or lowering on these kernels (or ensembles of kernels) that return modified kernels that can be more finely targeted to the users' desire. For example, a transformation could extract all (ancilla) qubits declared within the scope of a function to instead be imputs of the function:

@kernel
def main()-> None:
    qreg = bloqade.qasm2.qreg(5)
    bloqade.qasm2.h(qreg[0])

bloqade.passes.extract_qubits(main) ->
@kernel
def main2(qreg) -> qreg:
    bloqade.qasm2.h(qreg[0])
    return qreg

Or maybe a specific sub-kernel can be lowered to a different dialect set (such as qourier move-level), enabling the user to have finer control as to where the atoms are being moved around in the array. Low-level kernels (e.g., special waveforms for gates) could even be composed together as a "basic ingredient".

In this way, the (python) code that a user writes-- and their ultimate engagement with bloqade-- is an ensemble of writing kernels (defining ingredients) as well as manipulations of these kernels (cooking/mixing/souffléing) to get out the result of a highly tuned program. this requires a lot of very specific compiler passes to be written by SSW but I think it is one of the only ways we can avoid having Milan et. al. turn into compiler engineers that need to learn SSA.