Replace CFG diagram with mermaid.

[cqc-alec]

This replaces the first of the CFG diagrams.

It did raise one question for me: when a basic block (DFB node) has just one successor, the sum type in the predicate output should have arity 1. But there is nothing for it to contain, since all outputs would go in the other outputs (assuming we adopt the general policy of putting all common outputs there). Should we special-case this and omit the predicate output?

[cqc-alec]

Come to think of it this also applies if all successors want the same inputs. Maybe it is just a sum of null types in that case. Do we implicitly drop null inputs to a DFG?

[acl-cqc]

Come to think of it this also applies if all successors want the same inputs. Maybe it is just a sum of null types in that case. Do we implicitly drop null inputs to a DFG?

So the first Output in a basic block (i.e., the first input to the Output node) is a Sum type, each of whose elements is a Tuple. If there is one successor, that's a 1-ary Sum of some Tuple. The elements of the tuple are prepended onto the other (non-Sum) Outputs. So, a boolean is a Sum of two Tuples, each of which is a 0-ary tuple i.e. () aka "Unit". That is, bool == ( () | () ). I hope this answers your question about "null inputs" - when you prepend the elements of a 0-ary tuple to something, you prepend nothing to that something....

I really like your P? converting the unspecified P to a bool - much more satisfactory than the function I had before. And then H: P -> P makes much more sense :). However, I think there are some probably-unintended changes to the "wiring" inside the basic blocks - you're routing the angle and qubit through P? whereas they should go direct to the Output node. Moreover, the old graph also had explicit copy nodes, whereas I suppose we probably shouldn't have those anymore (?). Finally the "call it t" etc. names on the ports don't appear on the graph (the edge labels appear to be the types), so possibly mentioning them in the text might be confusing things.

I've not used mermaid, but I'd be quite happy take the opportunity to experiment with it a bit and try to write an alternative (into another branch, perhaps). But perhaps also you can see where you'd like to go from here!

[cqc-alec]

Thanks, that makes perfect sense, I was having a braino, forgetting that it was a sum of tuples and an empty tuple unpacks to nothing at all.

Thanks for pointing out the redundant wiring -- I'll fix that.

The "call it t" was to allow the verbal description of the operation; it doesn't need to appear on the diagram but I think it is needed for the text (at least to keep it concise). Maybe it could be better phrased...

[acl-cqc]

Ok, sounds good. Also the "..." - I think this doesn't need to touch the other values (they can be wired directly into the Output node), it just needs to be a (load)Constant, producing the 0-bit value whose type is (1-ary sum of (0-ary tuple)) - one might say, Only (), which is wired in as the first (input to the) Output (node).

[cqc-alec]

Oh, I realized that in order to make this PR self-consistent I should also update the diagram below that is equivalent to this one. Will add that next.

[cqc-alec]

Oh, I realized that in order to make this PR self-consistent I should also update the diagram below that is equivalent to this one. Will add that next.

Done.

[acl-cqc]

The first of these looks good - the difference in the two P? is perhaps a little confusing but basically fine. However, the second seems to be laid out terribly, to the point of being quite hard to understand. Screenshot below - I wonder if it's the same on your system, and/or whether there's anything we can do?
Let's remove attachments/2647818241/2647818458.png also.

[acl-cqc]

I think I'd label these "Const"

[acl-cqc]

Note the P? nodes in the graph are not doing the same thing - their types are different, as they are putting different values into the tuples (inside the sum). I'd either

1. reword this to suggest that they are different (perhaps even rename - P1 and P2, or Query1 and Query2, say); or,
2. use a simple bool type [()|()] everywhere, and therefore the same set of inputs (including both P and angle) to both BB1 and BB3, and then ideally note where the extra Inputs are being discarded. (Since we don't have explicit copy/discard anymore I'm not sure about the last, maybe it'd be ok to silently drop them).

[acl-cqc]

I was going to suggest BB1In -.-> BB1_["..."] i.e. use dotted edges for Order....but then I see you are using them for nonlocal edges. Hmmm. There are not many edge styles available :-(. How about making the nonlocal edges thick to emphasize them, as that diagram is specifically in the section on nonlocal edges? :)

[acl-cqc]

Can you combine A, qubit_source and angle_source into just A? That'd be more like the first diagram, and maybe it'd fit at the top then

[acl-cqc]

So most of the layout problem here looks to stem from mermaid putting BB1 as starting above BB2 (and adding a bunch of space inside BB1 at the top to make it high enough). I don't know why it does that, but I wonder if shuffling the order of BB1/BB2 might help?

[cqc-alec]

That makes no difference whatsoever, but let me see if there's anything else I can do to make it look more sensible.

[cqc-alec]

No joy, will make a github issue to revisit this.

[cqc-alec]

Looks like one can also apply colours to edges -- I might do that to distinguish dataflow from controlflow edges.

[acl-cqc]

Looks like one can also apply colours to edges -- I might do that to distinguish dataflow from controlflow edges.

Ah yes. If you have three colours for controlflow, order, and dataflow, which sounds good in itself, then you could also go back to nonlocal being dotted. As you like! :)

[acl-cqc]

Behaviour of mermaid renderer with nonlocal edges is sufficiently weird that we probably can't fix it :-(. But LGTM otherwise :)