Allow custom ops with static constant input edges

[ss2165]

This follows discussions mainly in #1308

A constant static input to an op would would be some semantically significant data, that cannot be lost like metadata. This could be thought of as "literal properties" or "intrinsic parameters".

If further we can elevate values to constants at compile time (constexpr evaluation) we can do powerful things with ops that need some structured, complicated, compile-time known data.

An open question is whether this data is available to binary compute_signature functions.

[doug-q]

I like this idea a lot, especially since we have lost CustomTypeArg. This allows well-typed custom ops to emulate child regions by taking a static edge of FunctionType. Since CustomTypeArg left, one would have to do this by encoding a Hugr into a TypeArg::String.

I think allowing compute_signature to see the static edge would be wrong. It is never necessary: one can always pass the signature as type args.

Consider modifying the Const Node that is providing the edge, such that the type does not change. We would want and expect that this should be mostly-fine. and so the signature of the node should not depend on the contents of the Const.

It is too much to hope for that this would be always-fine: maybe I need that node to have a Hugr in it, and it is replaced with a Const that provides a FunctionType by naming a symbol. Maybe the validation on the op would fail, or maybe some lowering could no longer be applied to the op. But we should degrade gracefully, there are many other operations on the Hugr that will be unaffected.

[acl-cqc]

It is never necessary: one can always pass the signature as type args.

If the signature is passed separately, isn't one then going to want a custom validation hook that can "check" the signature against the constant/static inputs? In which case, that's basically the same thing as compute_signature (just returning bool rather than Signature)...

It does feel a bit wrong though. Basic Hugr design is that a node determines its Signature which is to say, the ports incoming and outgoing. The values provided on those ports shouldn't affect this...

[doug-q]

Yes it does require a validation hook. However everything still works when that validation hook is not present, because the type scheme determines the op signature. This is a much better situation than nothing working because compure_signature isn't available.

I agree values on ports shouldn't affect it, which is why I say above that the values should not be available to compute_signature. The types of the edges on the ports are unnecessary, you can put type args in that fix them, and check in validate.

[acl-cqc]

So the validate hook has to be able to check not just the node weight and ports but also the static inputs to the op. That's a significantly bigger hook... (starting to look like an arbitrary function HugrView -> bool)