Comment by xyheme

I think it should be quite nice to write an interpreter in Haskell (and then introduce meta-circular to it?)

e.g. we can have Graph be a monad made up of `Node[]` with `runGraph` defined by somehow composing Rules

```

data PortType = ... deriving (Show, Read)

data Port = Port { portType :: PortType, portName :: String } deriving (Show, Read)

data Node = Node { inputPorts :: [Port], outputPorts :: [Port], principal :: Port } deriving (Show, Read)

```

Will need some creativity for the Rules to be defined more naturally, or it would end up just a function:

```

zeroAddRule :: Port -> [Port] -> Maybe [Port]

zeroAddRule target [addend]

    | target == outputPorts zero !! 0 = Just [addend]

    | otherwise = Nothing

```

[edited for elaboration]: I'm actually working on a LLM prompt-orchestration and fine-tuning/testing framework in Haskell (and will be open-source soon https://github.com/0a-io/ArchGPT ). The more I learn about iNet now the more I think I will try to write an implementation of it in Haskell and see how well it can fit into the hypergraph architecture I’m designing for building automated-software-development pipelines :)

I think what's so cool about the interaction-nets model of computation is that it makes tracing and stepping much more like first-class citizens, as well as a kind of intuitiveness for anything combinatorial

(X

Well, to be fair, making binary multiplication took more attempts that I would rather admit; I'm a programmer, not a mathematician XD

I also tried to make a game of life implementation, making use of the graph as a two-dimensional grid; however, it was too much for a single idle afternoon -- might have to retry that later. Main issue was trying to work around the stack-based part of the language (and I guess around port signed-ness); I can envision roughly what I want to get on the screen, but writing it out as stack manipulations, when there are so many cyclical references (ideally, I want every cell to be connected to up to 8 neighboring cells), is nontrivial -- especially when it comes to node rearranges, which, frankly, I didn't quite get. (:'

For self-hoisting, I would imagine the challenge would be around storing the rules and expressing the different node types. Tho - come to think of it, there are indeed two ways to implement it; one would be by defining a data structure to hold the graph and having an "interpreter" walk around the graph updating places where the rules match, and the other would be to define a sort-of composite "agent" which is able to correctly orient its primary port and interact with other composite agents around it, following the production rules it carries around. I guess that is pretty much what you are saying.. I'd say the latter/self-interpreting version is the more advanced one and would better benefit from improvements in the runtime, but the former should indeed be much simpler to write out.

For IO... I was thinking I'd rather have it at the graph layer, but now that you mention it, being able to customize it at the lower layer language would actually be quite neat.

And finally for implementation; the current JS/TS implementation is quiiite slow; it takes multiple seconds to crunch through a few thousand steps. Chrome profiler suggests the closeAllFreePorts function is the culprit; but I can't tell if that's an issue of the language or the implementation. Still, it might be worth keeping the JS/TS version for prototyping things out, then moving to another language only once things are more or less stable?