Model-local functions when creating a ModelProto from a python function about onnxscript HOT 3 OPEN

Another related feature is that of allowing potentially multiple function-definitions for the same op (in a code-base). It would be good if the underlying design enables this. It is also related to the notion of a "library" (a "LibProto" in serialized form) to represent a set of function-definitions bundled together. And to the ability to "link" a ModelProto against one or more libraries.

from onnxscript.

I suggest that we remove the embedded functions stored in the IR objects (for Stmt and Function), and instead make to_model_proto and to_graph_proto take a resolver object as a parameter, where a resolver is a dictionary-like object that, given a function-identifier (name, opset, version) returns a FunctionProto or None. The goal is to decouple the mechanism used to maintain a mapping from function-identifiers to their corresponding FunctionProto instead of hard-coding it into the IR itself. This will help address the key concerns, such as below:

The behavior of foo.to_model_proto() should be well-defined. As it exists today, assume that foo calls bar. If we do an import bar_def that has the effect of defining the body of bar, then foo_to_model_proto() will include the definition of bar as a model-local function, otherwise it won't. So, the behavior of to_model_proto ends up depending on hidden-state. It is better if the behavior is explicitly captured by an extra-parameter resolver of to_model_proto.

from onnxscript.

This would be nice 👍

from onnxscript.