Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify spelling of the bit literal #534

Open
jakelishman opened this issue Apr 30, 2024 · 5 comments
Open

Clarify spelling of the bit literal #534

jakelishman opened this issue Apr 30, 2024 · 5 comments
Labels
enhancement default GH label

Comments

@jakelishman
Copy link
Contributor

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 jakelishman added the enhancement default GH label label Apr 30, 2024
@jakelishman
Copy link
Contributor Author

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
Copy link
Contributor

jlapeyre commented May 1, 2024

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement default GH label
Projects
None yet
Development

No branches or pull requests

3 participants