RFC: Squin measurement return type

[johnzl-777]

In concluding #180 where consensus was reached on the state of MeasureAndReset/Reset statements as well as internal discussion and the existence of #257 there is a need to agree upon the return types of measurement-related statements in the squin dialect. As of now there is a bit of a mix between bool and int which is somewhat confusing.

For context: @weinbe58 has given the greenlight for the follow up on #180 to use Int for now so I can complete #148 but has also pointed out there is a Measurement enum that accounts for atom loss which could be desirable per discussions with @cduck . However, @Roger-luo has pointed out this does not exactly work well with QASM2.

In abeyance of standard RFC policy, with support from other members of the Scientific Software team, the triage label has been given on creation of this issue and a meeting will be set up soon to resolve the matter.

cc: @kaihsin

[Roger-luo]

I sometimes have the feeling - maybe measurement results deserve a special runtime, not IList[bool], not list[bool] but a special thing MeasurementResultList that provides the necessary runtime interface e.g indexing, iter and ideally a custom serialization format that reflects the necessary notation of atom loss etc.

Thinking about this futher, it is unclear if we support something custom in QASM2, e.g QASM2 does not return anything, it only says about the classical register storing the measurement result. While most of the case people will expect this is a boolean value, but maybe it is not very breaking to treat it as a special type.

Checking QIR spec here https://github.com/qir-alliance/qir-spec/blob/main/specification/v0.1/1_Data_Types.md#measurement-results it seems QIR is also treating the measurement result as a black-box, the problem is when the result is an atom loss, what does it mean to write

if result:
   pass

this should be a true or false or there should not be a __bool__ defined at all? Then what about the following

if result == 0:
   pass

if result == 1:
   pass

I assume both should be false in this case?

[weinbe58]

I don't think we should restrict the measurement result of Measure to be MeasurementResultList In the atom shuttling dialect I would like to be able to represent the results of a measurement beyond a list of values to make it useful for users.

I would vote for something like MeasurementElementType and have the result be IListType[MeasureElementType, L] for Squin, and that way I can use that MeasurementElementType as some other kinds of containers in the atom shuttling measurement dialect to maintain type consistency.

For QASM2 since it has very different semantics from the rest of the stack I think we should treat it as a special case.

[johnzl-777]

Adding the conclusion of the triage meeting from last week, everyone is in agreement that the inconsistency in return types from squin will be abstracted away with a MeasurementResult type that different runtimes will be able to handle themselves. Another change to squin will have to be made to reflect this although as of now #265 should go through first after clarification has been made considering some confusion on my end about the conclusion of the triage meeting.