Suggestions for the plugin devloper side of the API about pennylane

[cgogolin]

• An even more radical change would be to move the looping over the operations in self._queue that currently has to be done in execute() out of the scope of responsibility of the individual plugins altogether. A lot of the things happening in that loop will be the same for every plugin (like checking whether operations are supported and of handling parameters) and so it would be good it not every plugin needed to replicate that code. Wouldn't it be better/enough if every plugin just had to define something like apply(op, wires), which would apply the gate/measurement appropriate for the given plugin and potentially return an appropriate result? I guess I will write the ProjectQ plugin internally like that, so that if you like this, we can take my implementation of execute() as a basis for the plugin agnostic implementation.

[cgogolin]

• @josh146 and @co9olguy: Please specify the life-cycle of a plugin Device more concretely. For example: With which sequence of calls to execute(), reset(), and shutdown() should the plugin be able to cope? Should a device be "reusable"? It would be best if you could do this by directly implementing unit tests that execute all life cycles that plugins must support.

[josh146]

@cgogolin I agree completely with your original comment, and I think I agree as well with the second comment. The easier it is for plugin writers, the better.