Validating boolean comparison of MeasurementResults

[david-pl]

We often want to write something like

q = squin.qalloc(1)
...
m = squin.measure(q)

if m == 1:
    ...

However, m == 1 is always False since m is a MeasurementResult enum, which can be 0, 1 or 2, where 2 represents atom loss.

When there is no loss, you can effectively represent the intended logic by simply writing

if m:
    ...

It is very confusing to users, however, that if m == 1 will never be evaluated. Especially, since there is no error or warning, but it silently evaluates to `False.

Writing if m is also not great since this would be treated as True, when the qubit has been lost (since bool(2) == True). Again, there will be no error, but only a silent bug in the code.

The proper way of writing the condition is

if m == MeasurementResult.One:
    ...

However, any of the above is completely valid syntax and won't issue any warning or error.I 'm not sure how we could fix this. It may even make sense to add a rewrite pass that checks conditions, or more generally, boolean operations, that include measurements and then rewrites that to the "intended" expression. I'm not sure, however, since it may not always be clear what the intention is and rewrites can fail.

Another possible solution would be to use ValidationAnalysis to raise an error or at least print a warning for boolean operations used with measurements. I'm leaning towards that one.

[johnzl-777]

Wait, wouldn't #550 resolve this?

[david-pl]

@johnzl-777 well, sort of. #550 is essentially syntax sugar for

if m == MeasurementResult.One

However, nothing is preventing (or even hinting the user) from using any other comparison, such as m == 1. There should still be validation to catch this, IMO.

[johnzl-777]

When you say MeasurementResult.One you're assuming the existence of a kind of reference enum, right? MeasurementResult to me is just a type.

On a side note I have a modification to MeasurementId analysis in #599 that carries the predicate info forward in the analysis to make sure it can be understood as a legitimate stim operation

[cduck]

As a user of a static-typed language (which kirin dialects kind of are) I expect a type error when binary operators (like ==) are used with incompatible types.

I vote for only one way to check if the measurement was a 1: if is_one(m): ...

[david-pl]

When you say MeasurementResult.One you're assuming the existence of a kind of reference enum, right? MeasurementResult to me is just a type.

Oh, sorry, I confused it with the Measurement enum we have for our PyQrack integration.

As a user of a static-typed language (which kirin dialects kind of are) I expect a type error when binary operators (like ==) are used with incompatible types.

While I agree with this idea, this is not how kirin behaves. You can use pretty much anything that goes in python with == and kirin will compile just fine. Consider this weird MWE:

from bloqade import squin
from bloqade.pyqrack import StackMemorySimulator


@squin.kernel
def main():
    q = squin.qalloc(4)
    x = 1
    m = squin.broadcast.measure(q)

    if m == q == x:
        x = 2

    return x

main.print()


sim = StackMemorySimulator(min_qubits=4)
sim.run(main)

This will even run without an error since the condition just evaluates to False.

So we somehow need to handle this. There are a few options:

• If, as @cduck suggests, we want to enforce type compatibility in operations such as ==, this will need to be done on the kirin level. I'm not sure how much that will break things, however. That is, unless we want to have a dedicated IfElse statement in squin that is different from scf.IfElse. @Roger-luo what do you think?
• We can use a validation pass that raises an error for MeasurementResult specifically. We can even hint the user to is_one and friends, which is at least nice from a UX perspective. Comparison of any other types will still behave as standard Python does, which shouldn't be too surprising for users, IMO.
• We can introduce a rewrite pass, that rewrites boolean operations including a MeasurementResult and an integer accordingly. However, I'd argue that this can fail (for example, how would you rewrite m == q, since that's just invalid), so we'd still need validation.

I'm open for suggestions here, but I will say that I'm leaning a bit towards validation here, since it seems to be the easiest change.