support literal boolean in ifelse condition

[jlapeyre]

Currently this importer supports tests on classical registers as the condition in conditionals. It seems that only if-else statements effecting dynamics circuits are supported.

But the OC3 spec includes if (true) { ... in examples. This is not difficult to implement. It would be useful, not least for testing thing such as scopes. But it's a bit narrow. Maybe some other cases of expressions that evaluate to a bool at compile-time would not be difficult either.

[jakelishman]

It's not hard to do from the compiler side but Terra can't represent it yet, so I didn't implement it; we'd have to stray too far from the input source, such as by eliding the entire if true (just making the block unconditional), or if it were if (false) then throwing away the block. In either situation we'd not be able to test scopes with it.

[jlapeyre]

Making the block unconditional or throwing it away is what I had in mind. I don't see the advantage of pushing this off to terra (even if it can handle this in the future).

I'm thinking of replacing this test:

    include "stdgates.inc";

    bit[1] mid;

    while(mid == "0") {
      h $0;
      mid[0] = measure $0;
    }

    qubit q;

with this

if (true) {
    reset $0;
}
qubit q;

I could also do the following, but it's not very nice

    bit[1] mid;

    while(mid == "0") {
           reset $0;
    }

    qubit q;

Someone could write an OQ3 program and use a constant at the top (or literal in a conditional) to select code blocks. The intention would be to select code at compile time.
I suppose we are mostly thinking about machine generated OQ, so people should select code blocks when generating the OQ code. But some OQ3 might be hand written.

I already almost completed implementing this for literal bool. As you know, it's fairly straightforward.

[jakelishman]

At some point, the question is "what is the purpose of this package?". This is not meant to be an optimising compiler, it's just meant to get programs into the closest possible Terra representation. We expect Terra to grow the ability to represent arbitrary classical conditions.

There's a very good reason to push it to Terra: we should have a clear distinction of which packages are responsible for what, or we'll end up re-implementing similar logic in many places. Terra will have the ability to do that, so it's appropriate for this converter to pass the most accurate representation of a program to Terra. We don't expect Terra to have the concept of const variables, which is why this converter does to the work of constant folding.