Return Future[bool] from measure (in v1)

[ss2165]

The guppy quantum execution model is a little unintuitive:

• calling primitive functions on qubits (gates) sends gates to the "quantum operation scheduler" in a given runtime. The gate may not be executed immediately.
• Calling measure sends a measure request to the scheduler, which also may not execute immediately. Given that future program may depend on the result of a measurement, completing a measurement causes all preceding operations to be flushed.

The measure function in std.quantum returns bool. To make sure the flushing doesn't happen any earlier than necessary, under the hood this actually is a future. The guppylang compiler compiles bool to bool | Future[bool] in HUGR. "Forcing" the future in this case becomes the "block on measure" request, at which point the future becomes a standard bool.

Certain operations, like resulting the measure or conditioning on it automatically force the measurement.

Proposal

I propose that measure return a true Future[bool] type. std.qsystem.measure_leaked already returns a Future[int] under the hood.

This is a breaking change because a program that previously was:

if measure(a):
    h(q)

would fail to compile and would need to be written as

if measure(a).read():
   h(q)

Though for simple cases like this it only increases verbosity, it allows the user to reason about when they want to force the measurement - and gives them a better mental model of the runtime, reducing the chance of "surprise" in their outcomes. (e.g. why does putting my result(measure) in a for loop cause longer depth programs?).

A common case might be doing some bitwise operations on the measurement result or collecting them in to an array - the explicit .read() invites the user to think about whether they need to do that then or whether waiting would be preferable.

A secondary benefit is that the arcane bool | Future[bool] handling in HUGR can all go away, significantly simplifying the compilation pipeline.

Breaking considerations

This is a big breaking change, so should not be taken lightly. If done, v1 would be the earliest we would want to do this.
Given current usage patterns, a lot of breakage could be avoided if result() could accept a Future, which should be doable. This means result("c", measure(q)) will continue to compile without breaking.

An alternative is to keep compiling the code by returning bool from measure still and introducing new lower level functions that return Future[bool]. Though existing code would continue to compile I would call this breaking since it would make existing programs perform significantly worse by always eagerly forcing measurements.

[bhayat-quantinuum]

I don't think that old code working, but silently degrading in performance is a good idea.

Personally, I'd be happy to swallow the pain of refactoring code for the benefit or being able to reason about my program's performance more easily.

[perlinm]

Seconding this. People that have thought about optimizing their programs would be quite disappointed from finding out that some their optimizations were silently voided months ago.

[jake-arkinstall]

If we support printing futures, it would be nice to add a (FUTURE_REF:T:$name, $future_id) in the result stream immediately.

Then when it is actually forced, we add (FUTURE_VALUE:T:$name, $future_id, $value) to the result stream.

Then in result processing (e.g. Selene's result_handling code) we can perform a lookahead and insert values back into the order users currently expect, and replace the future ref with a (USER:T:$name, $value)

Where this breaks existing use is when a measure is later followed by an exit before the read happens, in which case the measure doesn't happen and there is nothing to bind the value to. We could force any hanging references on exit for this case if we want to.

If we do no such reordering then I think that would be unfortunate without supporting formatted tags for results. Users will have no way of printing in a nested scope and recovering meaning from the results.

[acl-cqc]

• Prefer keeping measure as is (with current optimization/type-translation), deprecating for a bit, maybe then removing the optimization, finally remove the deprecated stuff...
• We'll need significantly more work on futures etc. to allow the user to explicitly turn an actual bool into a Future<bool>, also to construct a future that does && or || on two futures (esp. if that can "shortcircuit" i.e. only wait for one of the input futures - select rather than join....)
  • These "futures" are slightly unusual in that the producer may change its production according to knowledge of whether the consumer is blocking on it??
• What about python "implicit bool conversion" or explicit bool(...) as an (additional) alternative to read....
  • Not sure if we are ever likely to do async, but It's the read that you'd await not the measure... (putting a hidden await inside an implicit conversion seems a no-no)
• result accepting a future seems a definite yes/requirement, but could be part of a Future::map / Future::and_then if we had that
• ---> designing how Future::map/and_then work wrt. evaluation timing and captured state seems like a good first step