https://gist.github.com/bojidar-bg/85026fa70e6ba7b1862bf8226...
Would be really cool if we had more input/output options; also, I'm curious if it might be possible to self-hoist the language somehow.
I think I have just caught the first user of this little language :)
It is amazing that you can understand the language simply by my minimal amount of docs, and write this non-trivial example.
I will study your example and add it to the repository.
Your implementation of `Bin` reminds me of the implementation of binary number in minikanren ( http://minikanren.org ), in a book called "The Reasoned Schemer".
Self-hoist will be a very very interesting challenge!
(1) Maybe we can do it by firstly implement a low level graph processing VM, and compile it to the byte-code of the VM.
(2) How about self-interpreting? like lisp's meta-circular evaluator. Maybe this is even more challenging then compiling.
Either way, We will need some built-in primitive functions about IO, and also some primitive functions about string processing (to parse the syntax).
Maybe we can keep the core pure, and extend the lower layer stack-based language.
Should we do this in this JavaScript/TypeScript implementation? or to do this in a C/C++/Rust/Zig implementation? (the later seems have more potential to be practical)
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
If you made an implementation, I will make a list of implementations in the homepage ( https://inet.run ), and add your implementation to the list :)
------
I do not know much about LLM yet, but I like hypergraphs too :)
(I learned about it from Wolfram Physics's docs.)
I will not miss an issue there :)
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?
In the paper "Interaction Nets" ( https://github.com/cicada-lang/inet/blob/master/docs/referen... ), there is an example of 1-dimensional Cellular Automata. (Section 1.4. Example: Cellular Automata).
> About the stack-based layer of the language.
I have some concerns about it when deciding to use it, because it is so different from common programming languages. I am comfortable with postfix notation, because I am familiar with the Forth language ( https://en.wikipedia.org/wiki/Forth_(programming_language) ).
> About Rearrange.
I will improve the docs about it.
> About `closeAllFreePorts`
If `closeAllFreePorts` is the culprit, maybe it is because of my wrong implementation of the web frontend (not the language).
I should not call `closeAllFreePorts` in a loop.
see: https://github.com/cicada-lang/inet-website/blob/master/src/...
and: https://github.com/cicada-lang/inet-website/blob/master/src/...
It is a bug that I should fix.
I also implemented a command line program and a REPL: https://github.com/cicada-lang/inet#command-line-tool
Maybe a few thousand steps will not be slow there.
we will probably need some graph-theoretical way of defining the env for it to be able to spring up a towel of meta-circular interpreters
I removed the syntax of rearrange, and added a new builtin `@spread`, I hope it is less confusing now :)