docs: document generic comptime functions#175
Conversation
|
|
||
| Note how the input to the `ladder` function is of type `array[qubit, k]` so this comptime function is generic over the number of qubits. | ||
|
|
||
| Note that we cannot compile the `generic_ladder` function directly as the value of `k` is unknown at compile time. However we can call `generic_ladder` inside another function with a concrete `k` value. |
There was a problem hiding this comment.
Maybe it'd be instructive to call generic_ladder inside another function and compile it.
There was a problem hiding this comment.
Also I think it would be good to show the compiler error message when you try to compile it
| As we can see, the ``print`` statement is executed at compile-time. | ||
| We get 9 printed lines, highlighting that the ``for`` loop is compile-time evaluated as well. | ||
|
|
||
| With Guppy v1.0 and above, we can use generic variables in the type signatures of generic functions. Let's generalize the `ladder` function defined above to apply a chain of `cx` gates to a qubit array of variable size. |
There was a problem hiding this comment.
Do we want to specifically call out v1 changes in regular docs sections?
There was a problem hiding this comment.
I think its fine to call out version numbers for major features.
| @guppy.comptime | ||
| def generic_ladder(qs: array[qubit, k]) -> None: | ||
| for q1, q2 in zip(qs[1:], qs[:-1]): | ||
| print("Applying CX") |
There was a problem hiding this comment.
Why include the print here?
There was a problem hiding this comment.
I guess its helpful for building intuition on comptime. When compiling the function for k=7 we see k-1=7 prints.
|
|
||
| Note how the input to the `ladder` function is of type `array[qubit, k]` so this comptime function is generic over the number of qubits. | ||
|
|
||
| Note that we cannot compile the `generic_ladder` function directly as the value of `k` is unknown at compile time. However we can call `generic_ladder` inside another function with a concrete `k` value. |
There was a problem hiding this comment.
Also I think it would be good to show the compiler error message when you try to compile it
Co-authored-by: Mark Koch <48097969+mark-koch@users.noreply.github.com>
|
Maybe I should add something here about monomorphisation? Also maybe "generics" should be its own section. |
|
@CalMacCQ We have a generics section in the "Static compilation and typing" doc - there might be enough to say about generics to pull it out into a separate doc at this point? |
3 participants
closes #94
This is really quite a powerful feature so I'm sure we can think of some cool algorithms to implement for the notebook examples.
As for the language guide, I've stuck with the basic cx ladder for now. We can remove the pre-V1 workaround where we define a comptime Guppy function inside a Python function and just have a generic type in the function signature.