Add gates / hyperedges

[hmillerbakewell]

ZXFest feature request

[hmillerbakewell]

Proposal for introducing gates:

We could view a gate as an ordered collection of wire vertices. Four lists of wire vertices, starting in the top left and proceeding clockwise. Data would be "name" (string) then "reflection marker" (bool) then "reflection flags" (int) then arities (int, int, int, int). Should we allow user data? We may need to examine more use-cases before we include that as an option.

Reflection flags: 1st-bit: reflection top-to-bottom 2nd-bit: reflection left-to-right

Arities: Top, right, bottom, left

Some names can be reserved; creating a gate with this name will infer the (arity, style, reflection) data from the Theory.

Expected problems:

• Those wire vertices need to know they aren't boundaries
• Matching on gates is going to take time to set up and test
• !-boxes: All the gates we can express in this manner have defined arities, but we could have !-boxes on a leg of a gate to indicate extra legs. Gates could also be fully inside a !-box.

Storage

• Gates should be part of the graph specification (like edges and vertices)
• Bundling and unbundling could be done as qrules; need safeguards to warn when a gate is being given a second bundling rule.
• "Reserved names" are names that the user will use again and again to refer to the same gate, such as a CNOT. These will be stored in the Theory, can be given a defined style and arity, and made readily available for use.
• "Disposable names" are names that the system does not need to keep track of. Perhaps a derivation involves an oracle that is never touched by the system, but is included for clarity. The Theory doesn't need altering: Creating the gate "f" here doesn't mean the user ever wants to create another identical one, and may want the name back again.

Design

• Suggest names for gates, the same way VName gives increasing numbers
• "Plain" gates should be black font on white background.
• "Reserved name" gates get the same colour options as vertices, and the option of not displaying the gate's name
• The reflection marker should look like a black square protruding from the relevant corner
• The "natural" place for the reflection marker is the top-right hand corner, and we aren't using the usual triangle protrusion because all edges are available for connections
• Edges should be drawn on top of gates, to highlight when an edge is connected to an unnatural side of the gate
• Gates with too many or too few edges (if they have a defined arity) should quietly alert the user; the user may still be editing the graph

"Creating gate" and "bundle as gate"

Choosing "create a gate" on a given graph selection of wire vertices should make an intelligent guess at arity and create a gate there. "Bundle into a gate" on a graph should make an intelligent guess at arity based on the boundaries, prompt for a name, and create a bundle-unbundle rule.

Bundling and unbundling

The user should be able convert a graph to a gate, given a prompt for the name of the new gate. This should automatically create a rule that goes from gate-expanded to gate-as-gate. There should be a seperate directory for gates; consider having these auto-included in the rule application window for derivations.

Milestones

1. Gates can exist internally
2. Gates can be drawn on the UI
3. Gates can be created on the UI
4. Gates can be bundled and unbundled
5. Gates can be matched on like any other vertex