[WIP]: Proposal for allocatable types and generalization of initializers

[bettinaheim]

This proposal is work in progress. I am putting up a draft for early feedback and discussion.

[viktorveis]

Changing arrays allocation syntax from Qubit[4] to Qubits(4) is significant enough to have a separate proposal. And looks like this can be done independently from the initializers proposal.

[cgranade]

If I understand correctly, this does not modify array allocation (see microsoft/qsharp-compiler#589 for that proposal), but only the syntax for initializing registers of qubits.

[viktorveis]

Sounds good to me. Since we're discussing it here, I would like to better understand advantage of Qubits(4) over Qubit[4].

[viktorveis]

Do I get it right that these two code snippets are the same?

using (a = Qubit[3]) {  ApplyToEach(H, a); }
using (b = init(3) then ApplyToEach(H, _)) {  }

If so, how much value do we get from the 'then' keyword?

[viktorveis]

To me, it's not obvious from this statement that we allocated qubits and not something else. I think that it is important to keep 'Qubit' in the syntax. May be:

using (q = Qubit()) { } // Exists today
using (qh = Qubit(H)) { } // One qubit in the H state, uncompute upon release.
using (r = Qubit[3]) { } // Exists today
using (rh = Qubit(H)[3]) { } // A register of 3 qubits in the H state, uncompute upon release.
using (r2 = [Qubit(H), Qubit(X)]) { } // Array of two qubits in different states.

[cgranade]

Are initializers first-class values (i.e.: can I assign an initializer to a variable binding)?

[bettinaheim]

So far I was not planning to support that - they could literally only be used within allocation statements. I don't see a reason to support it at this time. You can always pass an operation that is elevated though. Do you have a use case in mind where you would want to be able to pass an initializer?

[cgranade]

Makes sense, wasn't trying to suggest that we need first-class initializers per se so much as to understand the scope of the proposal. Thanks for the clarification!

[cgranade]

Effectively, it seems this is a kind of overloading, in that Qubits can either have type Int ~> Qubit[] or (Int, Int) ~> Qubit[,]. Is that represented by a type parameter to Qubits?

[bamarsha]

The overloading on tuple arity seems weird to me - it's compiler magic that can't be expressed in the language itself. I don't think it would not be possible to write a custom initializer that does this. A type parameter would allow any type, not just tuples of Ints.

[cgranade]

If I understand correctly, this does not modify array allocation (see microsoft/qsharp-compiler#589 for that proposal), but only the syntax for initializing registers of qubits.

[cgranade]

If it's in scope, it may be helpful to use ApplyXorInPlace as an example, since that demonstrates how init/then can be used to really help out with preparing structured data. In particular, I think that builds well on the example at line 68.

[bamarsha]

Having two keywords init and initialize that mean different things seems confusing to me. It's similar to the fun and function distinction in F#, which I also think is not very intuitive.

[bamarsha]

The initializer argument tuple may be omitted if the required argument is of type Unit.

We don't allow omitting () when calling functions or operations. What is the reason to support it here?

[bamarsha]

Suggested change

The proposal is to syntactically distinguish the two cases. The table below contains examples for both cases. In the first case, the initializer consists of the keyword `init`, followed by the initializer argument tuple, the keyword `then` and an operation-valued expression. The initializer argument tuple may be omitted if the required argument is of type `Unit`. The second case follows the same pattern with the exception that instead of the keyword `then`, then keyword `within` should be used, and the operation-valued expression needs to support the `Adjoint` functor.

The proposal is to syntactically distinguish the two cases. The table below contains examples for both cases. In the first case, the initializer consists of the keyword `init`, followed by the initializer argument tuple, the keyword `then` and an operation-valued expression. The initializer argument tuple may be omitted if the required argument is of type `Unit`. The second case follows the same pattern with the exception that instead of the keyword `then`, the keyword `within` should be used, and the operation-valued expression needs to support the `Adjoint` functor.

[bamarsha]

Having three different types of callables in Q# is a lot, especially since initializer names overlap with both type names and type constructor names. The automatic conversion from e.g. LittleEndian(Qubit[]) to LittleEndian(Int) is also a little confusing - when I see LittleEndian(3), I have to remember that:

1. It's in an initializer expression, so LittleEndian refers to the initializer, not the constructor, which takes a different argument type.
2. The Int maps back to the length of a Qubit array, even though Qubit doesn't appear anywhere in the expression.

I think there is a lot of cognitive overhead needed to interpret this syntax, and I wonder if making the Qubit array explicit would be better, such as LittleEndian(Qubits(3)).