What can Extensions type args be used for?

[croyzor]

In our kinds of type parameters, we allow "Extensions", which is the type of sets of extensions. However, the things that we can do with this at the moment are quite limited. Is that a bug or a feature?

If I define a PolyFuncType which takes TypeArgs which check against [TypeParam::Extension] then I can create the type T = (TypeEnum::Variable(0, bound), bound). Note: the "bound" arguments don't make much sense here, but let's forget about that for now.

What can I now do with this type T? It seems all I can do is pass it to the next PolyFuncType I want to use as a TypeArg. I can use it as an input/output in function signatures, but then it would be ill-kinded and (hopefully!) fail validation. Currently, neither the extension_delta of a FunctionType, nor the input_extensions of a Signature will accept this Type in place of a concrete ExtensionSet.

This is good for correctness, at the cost of expressibility.

---

So what can we do with this TypeArg?

• Pass it in to other PolyFuncTypes
• Pass it into some custom func, which opaquely uses it for its compute_signature method

What can't we do:

• Use it in lift nodes
• Use it in function types
• Use it as the "concrete" resources of a node

---

What do we want to be the case?

[acl-cqc]

The intention was to be able to define something like call_indirect, so you'd declare a type variable of kind TypeParam::Extensions, and then accept an argument that was a function (a PolyFuncType with no binders, I guess) with some_input_and_output_types** and a delta of that type variable...

So in fact I think we should be able to do all the things you mention: use it in Lift nodes, use it in function types (where it makes sense, e.g. as the delta) , and use it as the concrete (input-)resources of a node (within the scope of that binder).

When you say we can't do that at the moment, have you tried ExtensionSet::type_var and/or ExtensionSet::insert_type_var? I admit this doesn't address the case of Lift nodes - can we perhaps change OpType::Lift to take an ExtensionSet rather than an Extension ? (That'd be more uniform, and make substitution of concrete ExtensionSets in place of variables much easier).

**the issue that call_indirect would have to have fixed arity of function being called is another problem. Hmmm. Let's make that a separate issue/discussion...

[acl-cqc]

@croyzor is there more TBD here or can we close this? Are there specific tasks that need adding? (fwiw I think "generalize Lift to an ExtensionSet" is simple enough and useful enough to be worth doing even if the long-term goal is to remove Lift nodes altogether.)

[croyzor]

We can close this, but I'll open up "generalise lift nodes to extensionset" as an issue