Architecture: can Transformer nodes be Function?

[liamhuber]

In principle, the Transformer nodes all just run a simple function -- can we make them all inherit directly from Function? Of course the constructor calls to generate the transformer node classes dynamically will look different, since the point there is that we know basically what the function should look like but the number/names of I/O varies, whereas when we transform a function into a node the function signature is already fully known, but after they're created they look remarkably similar. It would be nice to bring the architecture together this way to minimize the number of different node classes floating around -- ideally users should only ever have to deal with Macro and Function, where Function may come in the flavour of transformer/dataclass nodes rather than those being something actually distinct.

[XzzX]

I like the idea. Do you want to keep For as it is? If I get it correctly For is neither a Macro nor a Function.

[liamhuber]

I like the idea of For being directly a Macro, but For is rather different in that it destroys and recreates (parts of) it child graph on each run. If we can nicely make it play as a child of Macro, I would be happy, I'm just not as overwhelming confident that it will work like I am for Function and Transformer.

As a first step, let's anyhow do this here, and get While working in the same paradigm as For, and then see about reparenting the loops.

[liamhuber]

I should say, For subclasses do have their IO specified at the class level, so I don't see a fundamental philosophical barrier to making them Macros, at the moment I only have the lesser concern of technical challenge