One issue is that in it's current state, there are little to no optimizations. This means that any quil that uses defgate as sequence is almost certainly going to incur penalties in terms of how well quilc is able to optimize.
In particular:
"we could see some benefit to having a sequence-gate class which is a subclass of parameterized-gate. Some of the work below [gate-matrix function for sequence gate defs] can be factored out so that it happens once per gate (or even per gate definition), rather than once per invocation with a specific set of parameters. (For example: say a gate sequence has 50 non-parametric gates followed by a single parametric gate. The matrix of those 50 only needs to be computed once).
Taking a cue from the handling of exp-pauli-sum-gate, this would involve having an :after method for initialize-instance which sets the matrix constructor. Then, we'd have things arranged so that if we did want to do some optimizations, we could just hoist out of that closure." @kilimanjaro
https://github.com/quil-lang/quilc/pull/785 adds the defgate as sequence feature to the quil language.
One issue is that in it's current state, there are little to no optimizations. This means that any quil that uses defgate as sequence is almost certainly going to incur penalties in terms of how well quilc is able to optimize.
In particular:
"we could see some benefit to having a sequence-gate class which is a subclass of parameterized-gate. Some of the work below [gate-matrix function for sequence gate defs] can be factored out so that it happens once per gate (or even per gate definition), rather than once per invocation with a specific set of parameters. (For example: say a gate sequence has 50 non-parametric gates followed by a single parametric gate. The matrix of those 50 only needs to be computed once).
Taking a cue from the handling of exp-pauli-sum-gate, this would involve having an :after method for initialize-instance which sets the matrix constructor. Then, we'd have things arranged so that if we did want to do some optimizations, we could just hoist out of that closure." @kilimanjaro