ResourceSet in Signature

[acl-cqc]

Each node's Signature contains two ResourceSets - input and output. Since the Signature is computed by the OpType, we then need every OpType to be parameterized with at least one ResourceSet....right?

That seems annoying, so possible solutions include:

• Get the signature from the OpType (by calling a function), but then store it in the node (mutably), i.e. as extra/redundant data.
• Separate the ResourceSet info out from the Signature (and then store the resources in the Node) - this seems like the best option?? @croyzor
• We believe it is necessary to store ResourceSets (i.e. they cannot be inferred e.g. by unification) - right? (Even if the Hugr contains lift nodes?)
• Maybe EdgeKind::Resource was intended to provide a different mechanism? I didn't find any uses, so Sketch out resources + extension mechanism, update CustomType #186 removed it (see cb7d892 which passed tests locally)

[croyzor]

It seems wrong to me that resource requirements should be separated from the rest of the type signature, but there are certainly more compact encodings if that's the concern here. Resource requirements are metadata only required for type checking, which is true of the types specified for all arguments in the type signature. N.B. resources can only be inferred when the graph is available, which is not always the case!

I can imagine a couple of use cases for specifying resource requirements in the type signature (in YAML, from the plugin developer's perspective):

1. They can specify what resources (if any) the resource they're declaring adds to it's output wires. This is essential for effectively tracking the resource requirements on a graph. Alternatively, they could be inferred once/if the body of the graph is specified. In this case, we only really need to track the delta of the resources, dR (since they'll be staying the same or increasing). We can leave the input resources as an open variable R, and the outputs have requirements R + dR.
2. They can specify that they want the inputs to their operation to have no associated resource requirements (I'm not 100% in what case this would be desirable)
3. They can specify the resources that they expect in the inputs to the function, so if I'm writing a plugin that extends some Quantum resource, I should specify that Quantum is the resource required by the inputs, and potentially use types declared by the Quantum resource in the signature of my operation. This could possibly mean that a standard transformation from the Quantum resource can be used to rewrite the body of the function once it's provided.

The latter utility might not be necessary, if we can guarantee that the type the plugin developer specifies is the one from the resource that they imported before defining their operations.

So if we drop the latter two options, we could represent resource requirements as a field resource_delta: Option<ResourceSet> for the sake of a smaller memory footprint

[acl-cqc]

I think 1. is the only one that really makes sense. The Resource requirements on an edge tell us what resources were used to compute the value. An operation cannot change what resources were used to produce its inputs, as that's already happened.

In that sense, this looks more like a dataflow analysis than a type analysis; computing "resources used" is unidirectional.

So, since we say the type of a node is a function of (only) the OpType ("the type of a node" also being known as its Signature), I move that the dR, as you put it, belongs in the Signature, but the actual Resource requirement is a property of either the node or the edge.

[acl-cqc]

In that sense, this looks more like a dataflow analysis than a type analysis; computing "resources used" is unidirectional.

I admit this "looks" / feels is a rather vague, intuitionistic feeling, rather than anything precise....

So thinking a bit more. In what circumstances might 2. and 3. make sense? This seems a question of provenance - "where the values came from", rather than what they are. (Or perhaps a question of access control - "Qubits produced by the Quantum resource", not just any Qubits - but it doesn't matter how indirectly, so I'm not sure that works well). I'm not sure that that's something we want the type system to figure out. Note that if the idea is that the op will run the computation producing the input on some special hardware that doesn't support any resource, then the input should be a Graph type with no resources; and I'm totally happy that an operation taking Graphs should be parameterized by the Resource types encoded in the Graph type.

But, is there a situation where dR doesn't make sense? Well - maybe? - what if the operation discards one of its inputs (even, a fixed one!). This could be specified in a tool-independent manner by a fixed Hugr passed around in the Resource. The output from the "lowered" Hugr would then have a Resource that did not include that input...

So, a possible alternative to the "encoding dR in the Signature" is to pass the input resources to OpType::signature() as a parameter (maybe one ResourceSet per input), and for said same method to return one ResourceSet per output...?

[croyzor]

But, is there a situation where dR doesn't make sense? ...

I think this is fine. By adopting the dR convention, we're saying that the resource requirements across all of the inputs have to be equal. When the resource requirements are all the same, then it doesn't affect the signature if we drop one.

If we have one output it's resource requirements should still be the union of all those of the input wires. If we have no output wires, then the resource requirements don't really matter.

[acl-cqc]

Yes, I think this is a good argument, thanks :). I hadn't thought that all inputs/outputs would be the same, but by lift nodes, that is indeed the case :)

[acl-cqc]

There are ramifications here on serializing Opaque ops, too. Here we want to save the signature as part of serializing the OpType. Which would be OK if every OpType was parameterized by the input ResourceSet! The delta also works, as does storing the computed Signature in the node (for every node). However if we pass input resources into OpType::signature() then we kind of want Serde to do the same when serializing the OpType, which looks difficult.

[acl-cqc]

I'm also moving to reject my earlier argument that the representation should be able to support all the type signatures that we might get by lowering to a Hugr (which would allow, say, one output to be given a nullary Resource even if all the inputs had some resource associated - e.g. if that output were a constant). This is a form of rewrite; and rewrites do change the graph: specifically,

1. it allows executions which were not possible before (an "op" must be atomic, so all inputs must be available before any outputs are; which is not the case when replaced by a Hugr).
2. Rewriting totally can affect types. E.g. if I remove a Conditional node with constant predicate, and replace it with just one "arm" of the conditional, I potentially can get different (lesser) resource requirements as a result.

[acl-cqc]

One more thought in favour of dR - this unifies Signature with GraphType :-)

[acl-cqc]

I think this resolved, although additional thoughts in #285