Super stuff this, that's a very interesting approach.
I spent the better part of the last two years writing a (closed source, sorry) library that does some of this, and some other stuff besides (state machines, events, 'proper' strings with automatic garbage collection and allocation, message passing).
Maintaining static typing was a big pre-requisite for that library, without it too much of value would be lost to offset the gains. It was a very educational project for me, it definitely re-inforced the 'half of common lisp' meme.
To program a piece of software using that library no longer felt like programming in C, every now and then you'd see a bit of C shine through in the lower level code. The whole thing relied to a ridiculous degree on macro cleverness (something to be avoided, for sure) and other deep knowledge of how C works under the hood to get certain effects, and I found this part of it less than elegant (even if the results were quite a big step up from programming in C).
The main justification for doing all this was to straighten out a project that had become bogged down under increasing complexity and a failure to abstract out the common elements. Choosing C for this project was a poor decision but since there was not going to be any budging on that front I tried to make the job work out as good as possible.
It's quite interesting to see how far you can push C but at the same time you really have to ask yourself if you are on the right road if you find yourself doing things in such a manner.
Like Cello, the lib I wrote is a way to force the language to become another language, which always has drawbacks in terms of unintended side effects and long term support.
Probably better to switch to a platform that is closer to your problem domain (in this case, such as erlang, clojure or even go), as much as I liked tinkering with C it felt like we were making life harder than it needed to be.
I spent the better part of the last two years writing a (closed source, sorry) library that does some of this, and some other stuff besides (state machines, events, 'proper' strings with automatic garbage collection and allocation, message passing).
Maintaining static typing was a big pre-requisite for that library, without it too much of value would be lost to offset the gains. It was a very educational project for me, it definitely re-inforced the 'half of common lisp' meme.
To program a piece of software using that library no longer felt like programming in C, every now and then you'd see a bit of C shine through in the lower level code. The whole thing relied to a ridiculous degree on macro cleverness (something to be avoided, for sure) and other deep knowledge of how C works under the hood to get certain effects, and I found this part of it less than elegant (even if the results were quite a big step up from programming in C).
The main justification for doing all this was to straighten out a project that had become bogged down under increasing complexity and a failure to abstract out the common elements. Choosing C for this project was a poor decision but since there was not going to be any budging on that front I tried to make the job work out as good as possible.
It's quite interesting to see how far you can push C but at the same time you really have to ask yourself if you are on the right road if you find yourself doing things in such a manner.
Like Cello, the lib I wrote is a way to force the language to become another language, which always has drawbacks in terms of unintended side effects and long term support.
Probably better to switch to a platform that is closer to your problem domain (in this case, such as erlang, clojure or even go), as much as I liked tinkering with C it felt like we were making life harder than it needed to be.