Engines can't be re-used about projectq HOT 6 CLOSED

Most compiler engines have an internal state, so re-using them does not make sense unless you reset that internal state (so you might as well create a new object).

from projectq.

If that's the case, then the "engine list" should be a list of engine-state-creators. Keep the configuration data separate from the state data.

from projectq.

This is why default_engines creates the list and is not itself a list of engines.
The reason we do not want to enforce this in general is that it becomes very cumbersome to use.

from projectq.

In general I would say that ProjectQ has far too much mutability throughout its design. This is one of the more egregious cases, because compiler passes are the kind of thing you configure and then keep around,

from projectq.

The user might want to access the state of a compiler engine (e.g., resource counts, circuits, ... at intermediate compilation steps). So it is easiest if the user can provide a list of objects which he/she can access after compiling the quantum program. It then also doesn't make sense to re-use this engine_list for, e.g., a different quantum program.

from projectq.

The fix you pushed has helped with this a lot.

I do still think it's a good idea to somehow extract the engine linked list so that it is not inline with the engine instances, but I think you addressed the core of this issue.

from projectq.