Looking at the code, a great deal of this is non-portable and/or U.B, so I would hesitate to call it C. And I'm not talking about some hypothetical problems, but stuff that should surface quite soon. For example, this is how stack allocations are made:<p><pre><code> #define alloc_stack(T) ((struct T*)header_init( \
(char[sizeof(struct Header) + sizeof(struct T)]){0}, T, AllocStack))
</code></pre>
So far as I can see, there are basically no alignment guarantees here - the returned pointer to the char array is not guaranteed to be aligned properly for Header (which is a struct of a single void* field), nor is there any attempt to align T inside the array. If things get misaligned, on x86 and x64, it'll work (but possibly much slower than normal), but on e.g. ARM you'll get all kinds of weird things happening.
Cello seems to make its way to HN quite often. The author (also of buildyourownlisp.com fame) has previously posted his motivations for building libcello on HN: <a href="https://news.ycombinator.com/item?id=8800575" rel="nofollow">https://news.ycombinator.com/item?id=8800575</a><p>Another previous discussion: <a href="https://news.ycombinator.com/item?id=6047576" rel="nofollow">https://news.ycombinator.com/item?id=6047576</a>
> Can it be used in Production?<p>> It might be better to try Cello out on a hobby project first. Cello does aim to be production ready, but because it is a hack it has its fair share of oddities and pitfalls, and if you are working in a team, or to a deadline, there is much better tooling, support and community for languages such as C++.<p>Wow. Straight talk instead of salesmanship. High marks for that.
As a superstitious C programmer, typedefing (void star) feels like walking on the cracks in the pavement, crossing the path of a black cat, walking under a ladder, or squeezing a lemon under the full moon to me. These kinds of tricks seem very clever at first but there always comes a point when they start to break down. I'd be leery about using union in 2017, but typedefing (void star) is like putting on your underpants outside your trousers, thinking you're superman and jumping out of a window thinking that you can fly.
The style reminds me of some J implementations!<p><pre><code> #define DO(n,x) {I i=0,_n=(n);for(;i<_n;++i){x;}}
</code></pre>
<a href="http://code.jsoftware.com/wiki/Essays/Incunabulum" rel="nofollow">http://code.jsoftware.com/wiki/Essays/Incunabulum</a>
Cool. This is a bit extreme but on purpose I think, it is an exploratory project AFAIK. If I had my hands free I would spend my time writing a new C library since I firmly believe that the problems of C are, for the larger part, in its standard library and not in the language itself. C memory model is unsafe but if mediated by a sane library for strings, and if by default you have most of the things where bugs are put (data structures, facilities for parsing, ...) things get a lot simpler and safer.
IIRC Cello doesn't enforce type safety, which means you can foldl but it's not much different from writing foldl in C and using void pointers everywhere.<p>I had thought about trying to make a type-safe version of Cello but I eventually realized that I can't do it in cpp so at that point it became its own language and too much work (I did not write Cello).
There are several reasons why people use C, one of them is that the language makes it very explicit what generated code is going to look like. That's one of the reasons why Windows kernel is written in C (<a href="https://msdn.microsoft.com/en-us/library/windows/hardware/ff559740(v=vs.85).aspx" rel="nofollow">https://msdn.microsoft.com/en-us/library/windows/hardware/ff...</a>, <a href="https://view.officeapps.live.com/op/view.aspx?src=http://download.microsoft.com/download/5/b/5/5b5bec17-ea71-4653-9539-204a672f11cf/KMcode.doc" rel="nofollow">https://view.officeapps.live.com/op/view.aspx?src=http://dow...</a>). Libraries like this obfuscate source code.
Here's the author of Cello talking about the project at PolyConf in 2015: <a href="https://www.youtube.com/watch?v=bVxfwsgO00o" rel="nofollow">https://www.youtube.com/watch?v=bVxfwsgO00o</a><p>« In this talk I dig into the depths of my programming library Cello - a fun experiment to see what C looks like when pushed to it's limits. I'll cover how Cello works internally, some of the cuter tricks used to make it look and feel so different, what is in store for future versions of Cello, and why it is important to push languages to their boundaries. »
How about performance? As I understand, it uses fat pointers fat pointers and GC, so performance drop is expected. There are not many reasons to use C nowadays beside performance.