Show HN: iNet – A programming language for interaction nets

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

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?

My current plan is to programming with interaction nets directly, and to view Lamping's "optimal lambda calculus reduction" as an example.

I have not read Lamping's paper yet. But if it uses "Interaction Combinators", maybe I can not even do it in my implementation.

Because there are two version of inet:

(1) Lafont's 1990 paper "Interaction Nets"

(2) Lafont's 1997 paper "Interaction Combinators"

I implemented (1) where a port has a sign (input port v.s. output port). Given two ports, I can only connect them when they have opposite signs.

In (2) there is no input port v.s. output port, ports are not signed (Lafont called the signed version "directed" in (2)).

"Interaction Combinators" uses self interaction (rule about a node interacting with itself), it is not possible in signed version of inet.

Because one node only has one principle port, thus can not connect to it's own principle port, because the same principle port has the same sign, not opposite signs.

------

I said "programming with interaction nets directly", because it seems already a more practical language than lambda calculus, for we do not need lambda encoding to express datatype and pattern matching, we can define rules case by case directly.

I was on mobile and I think I accidentally clicked the gh link for the doc, and thought the readme was the doc

would be cool to have a server-rendered page