Comment by bojidar-bg
1 year ago
(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?
> About the game of life.
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.
Would you mind elaborating on your idea of the composite "agent"? I don't quite understand it, and it does not sound like what I think OP's metacircular evaluator is referring to.
Well.. hm. Basically, in a "normal", non-self-hoisted interaction net you have agents that have principal ports and interact with each other -- in iNet, those are called nodes. So, I'm thinking it might be possible to make a self-hoisted interaction net by replacing each custom node/agent in the original "normal" net with a subgraph which is composed entirely of reusable nodes that implement the self-hoisting. And, I'd imagine that such a subgraph would have a single principal port pointing in the same direction as the "normal" agent's principal port did, plus an internal set of nodes which encode the rules. Hence, each "normal agent" is turned into a "composite agent" -- if that makes sense.
ooh interesting. So it’s kind of like having iNet inside iNet, like node is implemented as an iNet itself (or a sub-iNet)?
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
> ... when it comes to node rearranges, which, frankly, I didn't quite get.
I removed the syntax of rearrange, and added a new builtin `@spread`, I hope it is less confusing now :)
If you use telegram, welcome to join https://t.me/CicadaLanguage