Clarify spelling of the bit literal

[jakelishman]

What is the expected enhancement?

We have a spelling for bool literals (false and true) and a spelling for bitstrings ("00101" for bit[5]), but it's not clear to me from the spec what the spelling of a single scalar bit value is. bit[1] would be the strings "0" or "1" and bool is listed as explicitly casting to that, so can we clarify that bool can implicitly cast to bit (the scalar, not the family) and use the Boolean literals for bit? Alternatively, the integer literals 0 and 1 for bit.

My motivation is that I need to know the literal syntax to spell setting a single bit out of a larger integer, like:

uint[8] c;
c[0] = /* ? */;

A related point is whether bit and bit[1] actually are distinct types. My type-theory purism likes them to be distinct, but that's mostly philosophical. For sure it feels easier to implement the type system like that to me, and it makes it easier to talk about broadcasting in measure.

[jakelishman]

It may make life easier to declare the scalar bit and bool to be identical in allowed operations, but I'm fairly sure we've discussed that before and there's more considerations than I can immediately remember.

[jlapeyre]

OQ3 is already liberal with implicit casting. Sticking with that tendency, I'd say that both

c[0] = 1;
c[0] = true;

work and have the same semantics. But I say this after thinking about it for 60s.

bit and bit[1] actually are distinct types

You mean a scalar and a bit array of length one? Those should definitely be distinct types, right?

[blakejohnson]

I'm not sure where I stand, but to throw out another option, we could also introduce single-quote strings for bit literals, e.g. a bit could take values of '0' or '1'.

As for the distinguish-ability of bit and bit[1], I hear you on on the type purism argument. I would simply counter that OQ3 effectively treats qubit and qubit[1] as equivalent, so we should also examine consistency of the language in that respect.

[jakelishman]

You mean a scalar and a bit array of length one? Those should definitely be distinct types, right?

Personally I'd say strongly yes, but there's arguments to be made along the vein of implicit casts and "what does bit[_] mean anyway?" that maybe not. In writing this, I remembered that Blake and I had talked about it on Qiskit a little while ago that I'd forgotten to bring over here, so I opened #535 to do that properly.

[jakelishman]

Blake:

I would simply counter that OQ3 effectively treats qubit and qubit[1] as equivalent, so we should also examine consistency of the language in that respect.

Does it for sure? In #535 I was giving examples of how I'm not entirely sure that it actually does, when it comes to broadcasting - at the very least, it'd be good to clarify it in the spec one way or the other.

The short form of my question is, given:

include "stdgates.inc";

qubit[2] a;
qubit[2] b;

cx a[0:0], b[0:1];

where a[0:0] is an explicit range of qubit[1] as opposed to a single qubit a[0], should the broadcast work or be an error? To me it's a clear semantic error that we'd want to catch and tell the user they made a mistake with (probably a typo), with no benefit to allowing that syntax, rather than silently doing something different. That to me motivates qubit and qubit[1] being separate types.