RFC: qubit dialect structure conformity with gate/broadcasting

[johnzl-777]

Currently the qubit dialect, under the squin umbrella, contains key statements for writing squin programs but makes UX a bit odd (unless you explicitly import qubit as a separate thing but this harkens back to QuEraComputing/bloqade#287)

from bloqade import squin

@squin.kernel
def prog():
	q = squin.qubit.new(10)
	squin.x(q[1])
	squin.broadcast.h(q)
	measurement_results = squin.qubit.measure(q)

It would be much nicer if a user could just do squin.measure instead. I understand post- #518 the qubit.new will be a nicer squin.qalloc.

I realize a particularly easy way would be to just do some kind of re-export but then if we have operations like Reset (pending a wrapper: #545 - one that I'd like to add post conclusion on this RFC) is it best they follow the split we have between single and broadcasted qubit operations? Or should Reset follow something like Measure with a MeasureAny blanket statement + desugaring?

I think of a similar issue for get_qubit_id and get_measurement_id. Right now they only accept singular instances of Qubits and MeasurementResults. Do we want them to be broadcastable too? Like

qs = squin.qubit.new(10) 

ids : IList[int] = get_qubit_id(qs)
# but could also do 
id: int = get_qubit_id(q[0])

[weinbe58]

sounds good. also reexporting will be easier once qubit is at the top level anyways.

[johnzl-777]

@weinbe58 wait, what exactly sounds good out of this 😅

I think to be more precise I'm asking if

1. qubit statements should become directly accessible via squin directly and
2. If so, should they be broadcast-agnostic (you can put a single item or a list of items, which would introduce additional complexity because it would have to follow something like measurement desugaring) or if they should conform to everything in gate/stdlib which gives you the distinction of single/two-qubit vs. broadcast but which makes things weird in my opinion (like squin.broadcast.measure seems silly)

[weinbe58]

I think for operations that act on qubits it should be something similar to gates.

m = squin.measure(qs[0])
m_list = squin.broadcast.measure(qs[::2])

Reset is basically a gate operation so it can be treated as such IMO.

Allocation is a separate operation so it doesn't make sense to follow that broadcast convention.

[johnzl-777]

Yeah that sounds pretty reasonable to me! I suppose my final question is the following:

for something like get_qubit_id(qubit) -> int should that be broadcastable too considering it consumes qubits? And if we make that broadcastable should get_measure_id(MeasurementResult) -> int have something similar?

[david-pl]

As a side note: if we change the semantics to squin.measure(q: Qubit) and squin.broadcast.measure(q: IList[Qubit]), we can get rid of the MeasureQubit statement (basically replace it by MeasureQubitList) and the MeasureAny statements along with desugaring.
From past experiences with ApplyAny and friends, I'd say this is another argument as to why this would be beneficial to have since it simplifies the dialect and avoids situations where the desugaring fails leading to implementation errors down the line.

@johnzl-777 regarding your last question: why not have this broadcasted? That wouldn't hurt and we reduce the special casing to qubit allocation only.

[johnzl-777]

@david-pl You're right, I suppose I was just seeing if there would be any reservations to expanding @weinbe58 's convention to something that doesn't consume qubits.

I'm all for chopping out more complexity!

I think once #518 gets merged in this RFC should be implemented (and then the blocked issues can go through too because qubit will have both semantic and code form that aligns with #492 (: )