Wrote a mini CSP in static C for bare metal uC work. Needs some real-world use testing still, but I like how it turns out to be fairly simple. github.com/zwizwa/uc_tool
Conversation
I had been looking for a "mini Erlang" before, but really CSP's synchronous nature is a much better fit for static allocation. I learned a couple of surprising things doing this. See comments in csp_test.c csp.c csp.h
2
I'm going to have to write an OS now. Started decoupling STM32F103 hw from the CSP scheduler. I like having an OS as a library: make it very easy to test code on Linux before moving to uC.
1
2
Thanks for spelling out that the essential part in CSP/CML is synchronization of two tasks. The direction of data exchange can be thought of as secondary and that is clear in implementation: send and receive look almost the same. Very different from the Actor model.
1
2
Variation on the scheduler theme: Erlang implementation of redo: github.com/zwizwa/erl_too, can be abstracted to operations over generic (distributed) store. Thanks to for implementing redo and writing about it.
1
This is a "pull" implementation. I wonder if a "push" implementation is possible as well while using the same dynamically reconfigurable dependency idea from redo.
Push is straightforward once there is a dependency graph, i.e. after the first run. The key is to invert the dependency graph, collect the outputs affected, and then pull those.
1
More insights: 1) "make" is a trivial special case of redo, 2) separating scheduler from the file system makes it a lot more flexible. I.e. you're just scheduling abstract updates on an abstract store. One special case of that is files + shell scripts.
1
I like this abstract approach. This way, a "compiler" can be a stateful service. E.g. ghci is fast for small changes, but it takes long to rebuild cache on restart. Doing the "build script" in Erlang makes the protocol part easy. No more messing with strings in shell scripts.
1
The next step was to extend the reference system (build inputs and outputs are keys into some abstract store), and put values and pure functions into the mix. I think it was good to be tricked into doing the stateful ref part first, because now it all just fits together.
1
Added process and uC board restart as part of the state that is managed by this. Too bad I didn't realize it earlier. Could have avoided a messy rube Goldberg Machine. Moral of the story: Erlang is a great network operating system. Live code reload is an essential part of it.
1
Realized that "react" can be implemented on top of redo by slightly re-interpreting change propagation and introducing a side channel for subtree updates.
1
This is subtly different. Interesting design space tho.