Static functions as type arguments

[zrho]

i.e. whose kind is a monomorphic function type, and the arguments are instantiations of functions in the Hugr. (static instantiations, but perhaps passing other static function arguments).

These can be targets of Call nodes (not IndirectCall - they do not depend on runtime values) - hence are turned into direct calls to FuncDefns/FuncDecls by monomorphization.

[acl-cqc]

I kinda feel that doing this in hugr-core would not be that difficult - a new TypeParam, containing a FuncValueType, and a new TypeArg, containing a Node. (Modulo, do we need to parameterize by Node...)

The key issue then is that you can no identify all the calls to a FuncDecl/FuncDefn just by looking at its successors / linked_inputs, so we need to start introducing better analysis here (e.g. via CallGraph?). This could be a much larger change (perhaps a full-scale move towards model Terms?? Or, is there some sneaky possibility that we could add every Call/LoadFunction (of function X, using function Y as a static argument) as a successor of both X and Y??)

[zrho]

In hugr-model, a static function with input types ?inputs and output types ?outputs (which are both lists of runtime types) has itself the type (core.const (core.fn ?inputs ?outputs)). A first and easy step would therefore be to introduce a TypeParam variant for constant types. This is slightly more general than your proposed variant that holds FuncValueType; the additional generality is very useful for an eventual migration of the constant system in general. I have created an issue for this here in case someone else wants to attack this: #2304

[zrho]

This has become relevant to #2028: some remaining failing tests are related to function constants.

[zrho]

After #2411 merges, the next step is to add Terms that refer to (function) nodes in a parent Hugr. If we used Nodes directly, compacting the index space would need to traverse terms in order to reindex the references. The hugr-model text format gets around this by allowing references to functions by their name. In hugr-core we can not use the function's name as a stable id since names for private functions aren't unique.

[acl-cqc]

I am thinking that traversing terms and reindexing references may indeed be necessary, and might (want/need) to be connected with CallGraph

[acl-cqc]

If we've done #2756 and all the things in there, we'd still need to parametrize Term by Node (and add a new Term::LoadFunction); doing this whilst retaining dyn CustomConst will be painful, but maybe less bad if we've done #2296 as well.