Clarify whether defcals can be defined using aliases

[amilsted]

What is the expected enhancement?

It isn't clear to me whether the following is supported:

let q0 = $0;

defcal X90 q0 {   // equivalent to `defcal X90 $0 { ... }` ?
    ...
}

It seems like a natural and useful thing to support, as naming physical qubits (rather than referring to them only by integer) can clarify code e.g. in cases where there is more than one type of qubit on a device.

I could not tell from the spec whether this is allowed, so perhaps this should be clarified?

[jwoehr]

Physical Qubits
While program qubits can be named, hardware qubits are referenced only by the syntax $[NUM]

I take "only" to mean "only" but I can see how the discussion of Aliasing can lead to ambiguity.

Aliasing
The let keyword allows quantum bits and registers to be referred to by another name as long as the alias is in scope.

I have opened Pull Request #473 to address this.

[amilsted]

Gonna reference #471, which also makes the case for more flexible references to hardware qubits. @PhilReinhold I think that issue should probably be reopened.

[blakejohnson]

I would say that the q0 referenced in the definition:

defcal X90 q0 { }

is not the same q0 as in the surrounding scope. This is also true of how variables in def statements can shadow variables in their enclosing scope. e.g.

int a = 1;
def foo(int a) -> int {
   // in this scope 'a' references whatever was passed in, not the value of 'a' in the enclosing scope.

[amilsted]

Ah, I hadn't realized that defcal X90 q0 { ... } is already valid and defines a generic defcal.

Perhaps we can reopen #471 and consider more flexible physical-qubit names like $q0 instead?