4 ms·

This sounds a lot like what I was considering. Initially I had a uC/OS kernel and added the equivalent of sleep()/wakeup() and the AmigaOS message ports. QNX to

This sounds a lot like what I was considering. Initially I had a uC/OS kernel and added the equivalent of sleep()/wakeup() and the AmigaOS message ports. QNX took messaging to the extreme (in my opinion :-) but it makes a good way to delineate taskable data. Back at NetApp I was trying to accelerate file processing and realized that files (and mutations thereof) were just a state machine which (and this isn't new or anything, log file systems are an extension of this observation) but the interesting thing was how you could project a sequence of state transitions and reliably determine if it was possible to jump to the end state or not. (and yes this is basically optimizing non-directed graph traversal using robot state which can be reflected in external things like actuator position) The games people are doing these sorts of things to animate elements of their game environment which I find pretty cool too. Once my Tilt5 glasses arrive I expect I can play with this in 3Space using Unity and the SDK which will make it less of a thought exercise and more of a visualization exercise. Guessing that lookalive-software is your github, have you put up your thoughts anywhere? Would love to read through them.

jazzyjackson 5y ago
thanks for the interest, the implementation has been in stealth mode but an old first draft description of the language is at https://lookalive.software/ https://lookalive.software/ Could you say what it means to 'project a sequence of state transitions' ? I am not hip to the CS lingo - you could say I am scanning the AST for tasks whose prerequisites include no further tasks, and replacing the branch of a completed task with its result. Essentially all I'm doing is asking the coder to write an AST directly, except expressions can be mixed in with literals. I was just doing a kind of handlebars/mustache templating engine with JSON before realizing I had all the pieces for a general purpose language. My hello world(s) looks like: {"body": [ {"#!cat planets.txt": [ {"h1": "#!echo hello :0"} }] ]} The interpreter scans the JSON for the #! token and checks if all the parameters are literals, so first it hits #!cat and sees the argument 'planets.txt', OK, nothing further to compute, pass it off to a subshell and get the result, say, `mercury\nvenus\nearth\mars`. Newline separated results get interpreted as an array, and arrays are mapped over the next branch of the tree to get: {"body": [ {"#= mercury": [ {"h1": "#!echo hello :0"} ]}, {"#= venus": [ {"h1": "#!echo hello :0"} ]}, {"#= earth": [ {"h1": "#!echo hello :0"} ]}, {"#= mars": [ {"h1": "#!echo hello :0"} ]}, ]} At this point, there are four branches of the AST that have no shared dependencies, so my interpreter can solve them in parallel: before `#!echo` is ready, the colon marks a named (in this case numbered) argument to lookup so "#!echo hello :0" gets replaced with "#!echo hello mercury", and now all four echo branches can be forked in parallel. (If you're asking why I have to use a subshell and the echo program just to concatenate two strings, it's because the language has no builtins except #=, #&, #!, and #? ((for label, lookup, solve, and switch)). You can define functions but I wanted to start off with builtins provided by the OS, communications overhead be damned.) The '#=' then collapses once it's children are all literal so the final state of the program is: {"body": [ {"h1":"hello mercury"}, {"h1":"hello venus"}, {"h1":"hello earth"}, {"h1":"hello mars"} ]} Which can then be translated to HTML by `github.com/lookalive-software/elementary` -- besides the parallelism and declarative/functional style, my selling point is being able to step through the process, so the editor is able to rewind the state, adjust something, and resume execution. Every state is a new valid program (valid JSON too), so if you want to pause the program, upload it to a bigger computer, and resume you can do that to. Not sure if those were quite the thoughts you were looking for, but I've been meaning to start writing docs for the current implementation anyway, so thanks for the push. If you want to know more details about the queueing / scheduler, I need to write the docs for that too ;)

jazzyjackson 5y ago

thanks for the interest, the implementation has been in stealth mode but an old first draft description of the language is at https://lookalive.software/ https://lookalive.software/ Could you say what it means to 'project a sequence of state transitions' ? I am not hip to the CS lingo - you could say I am scanning the AST for tasks whose prerequisites include no further tasks, and replacing the branch of a completed task with its result. Essentially all I'm doing is asking the coder to write an AST directly, except expressions can be mixed in with literals. I was just doing a kind of handlebars/mustache templating engine with JSON before realizing I had all the pieces for a general purpose language. My hello world(s) looks like: {"body": [ {"#!cat planets.txt": [ {"h1": "#!echo hello :0"} }] ]} The interpreter scans the JSON for the #! token and checks if all the parameters are literals, so first it hits #!cat and sees the argument 'planets.txt', OK, nothing further to compute, pass it off to a subshell and get the result, say, `mercury\nvenus\nearth\mars`. Newline separated results get interpreted as an array, and arrays are mapped over the next branch of the tree to get: {"body": [ {"#= mercury": [ {"h1": "#!echo hello :0"} ]}, {"#= venus": [ {"h1": "#!echo hello :0"} ]}, {"#= earth": [ {"h1": "#!echo hello :0"} ]}, {"#= mars": [ {"h1": "#!echo hello :0"} ]}, ]} At this point, there are four branches of the AST that have no shared dependencies, so my interpreter can solve them in parallel: before `#!echo` is ready, the colon marks a named (in this case numbered) argument to lookup so "#!echo hello :0" gets replaced with "#!echo hello mercury", and now all four echo branches can be forked in parallel. (If you're asking why I have to use a subshell and the echo program just to concatenate two strings, it's because the language has no builtins except #=, #&, #!, and #? ((for label, lookup, solve, and switch)). You can define functions but I wanted to start off with builtins provided by the OS, communications overhead be damned.) The '#=' then collapses once it's children are all literal so the final state of the program is: {"body": [ {"h1":"hello mercury"}, {"h1":"hello venus"}, {"h1":"hello earth"}, {"h1":"hello mars"} ]} Which can then be translated to HTML by `github.com/lookalive-software/elementary` -- besides the parallelism and declarative/functional style, my selling point is being able to step through the process, so the editor is able to rewind the state, adjust something, and resume execution. Every state is a new valid program (valid JSON too), so if you want to pause the program, upload it to a bigger computer, and resume you can do that to. Not sure if those were quite the thoughts you were looking for, but I've been meaning to start writing docs for the current implementation anyway, so thanks for the push. If you want to know more details about the queueing / scheduler, I need to write the docs for that too ;)