I want to make a few observations about this, and why I found it seemingly less "hacky" than other such attempts:<p>- As I said in an earlier comment, "var" is just a typedef'd "void *". The downside is that libCello code is essentially untyped, but the upsides are that the C preprocessor is now enough to do the processing needed for the rest of the macros in the language, and that you can still mix regular typed C with libCello code for a "best of both worlds" mix.<p>- Looks pretty, right? What you're responding to is not just the nice non-capitalized macros and the $ keyword, but the syntax highlighting in his examples. Fire up a text editor and write you some libCello code without this highlighting and it probably won't feel as nice.<p>I'm extremely interested in the idea of taking the syntax highlighting, formatting, and code completion OUT of these specialized IDEs and plugins and into some kind of standard "bidirectional channel" between a language processor or compiler, its macro system, and the user's editor of choice.<p>We should be able to make entire DSLs and specialized syntaxes that not only compile, but are able to provide rich information to the surrounding development environment in a standardized way. I'm not alone on this. F#'s Type Providers do exactly that. But imagine being able to control not only the "intellisense", but also the syntax highlighting, argument/return tooltips, documentation, preferred formatting, snippets, etc.<p>And by "surrounding development environment" I mean everything from the command line to vim and emacs all the way to Sublime Text, Eclipse, and Visual Studio. Even github! Why do you have to register a new syntax highlighter on github for a language and hope they turn it on?
Super stuff this, that's a very interesting approach.<p>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).<p>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.<p>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).<p>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.<p>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.<p>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.<p>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.
Slightly related tangent:<p>I'm looking for standards / set of libraries / best practices for "modern" C development, but I've yet to find a comprehensive resource.<p>Stuff like typedefing a manual fixed sized int type to be cross-platform compatible, that books don't really tell you to do but are important and come up often.<p>I'd be okay with a small, well written example library too. Does anyone happen to know something like this?<p>edit: Ah, sorry if I misled you, that was just an example of the <i>kind</i> of tips and pointers I was looking for. Or weird bits like the linux kernel list_head. <a href="http://kernelnewbies.org/FAQ/LinkedLists" rel="nofollow">http://kernelnewbies.org/FAQ/LinkedLists</a> Or common libraries like bstring that make life easy. Or even a single, comprehensive implementation of good data structures, since everyone seems to have their own vector.h and/or hash.h that fails to cover much other than their own use case.
Wow, this is an impressive amount of high-level feel for relatively little preprocessor code (and a fairly lightweight C library underneath that). Holds together pretty consistently, which is hard to do with syntax extensions built on top of the C preprocessor, vs in languages with more convenient syntax-extension or macro systems.
I spent the last hour trying to get the example programs on the front page of the libCello site to compile on OS X (10.8.4). I discovered I was missing some include flags. This is what finally worked:<p>$ gcc -lCello -std=c99 -fnested-functions example.c -o example<p>Hope this helps someone!
Note that "var" is a typedef'd "void *". This essentially bypasses C's typechecker for libCello code. The author admits as such, and maybe that's just fine for what you need to do, but you should be aware of it.
After looking at the source, this appears to be a great beginners resource of how to build on top of C. The source is very concise and straightforward. I'm curious to see what will come from this.
People interested in real-world high(er)-level C programming should take a look at this book, "especially the class methodology in Chapter 4": <a href="http://www.duckware.com/bugfreec/index.html" rel="nofollow">http://www.duckware.com/bugfreec/index.html</a><p>Side note: this book would certainly be down-voted on r/programming but I expect more grown-ups here.
An interesting experiment, but even as the author states "it's a fun experiment". It makes things easier to read & understand for beginners, maybe, but he even states that it's not for beginners. If I have to be a C power user to use it, I imagine I'd feel more comfortable without it. Just my opinion though.
Pretty cool, even if I don't want to see the compiler warnings. ;-)<p>In the same vein, but more C-like: <a href="http://p99.gforge.inria.fr/p99-html/" rel="nofollow">http://p99.gforge.inria.fr/p99-html/</a>.
What is this? It claims to be a (GNU99) C library, but I don't see how this can be the case, considering all the non-C constructs in the sample code ($(), try/catch, foreach). So it this just a language of its own that is compiled into C?
This is the kind of functionality that D language is really good at. If I were to go beyond the fun bit of this project, i would have a look at D language.
Chello is nice proof of concept, but personally i'd like to see only one or two changes to C standard:<p>1. sizeof(function) -> would give user ability to copy functions around.<p>2. maybe new reserved keyword _Func -> function tagged with _Func would indicate that function must be compiled as function object (defined sizeof) and compiler needs to address fact that function may be moved around and used (relative addressing and i guess bunch or others problems that would arise). Only code, nothing to do with ELF or other formats.<p>Another interesting thing to do would be to, somehow, eliminate function pointers with _Func.<p>In any case, user would be responsible for creating environment for that (lambda?) functions, like manually setting mprotect or setting up stack (prologue.h & epilogue.h ???).<p>_Func int example_prototype(int i, int j) {<p><pre><code> return i + j;
</code></pre>
}<p>And then do something like:<p>example_prototype func0;<p>memcpy(&func0, example_prototype, sizeof(example_prototype));<p>struct prologue_t *p_ptr = &func0;<p>p_ptr->sp = 0xdeedbeef; // Or some address that is used as stack<p>z = func0(5, 6)<p>So, what do you thing how hard would it be to implement something like that?
This looks very nice indeed. The main thing that will interfere with usability for me as a non-C guru is the lack of thread support. But I am really grateful for the effort since my "spiritual home" among programming languages is definitely the dynamic languages, yet I appreciate the need and beauty of C in many instances when performance is necessary. libcello's apparent optional static typing (the "var") is really nice -- it's one of the wonderful things about using Cython alongside Python.
So, because I am a nub in this stuff... When it says C library, does that mean anything that works with C (say a gui library for example GTK) will work perfectly fine with this? I would just change the syntax as required and call it good?
It seems interesting but I did not get it. Does it try to add some c++ syntax sugar? Does it have performance advantage over c++ for similar functionality?<p>I am not a fan for C++ syntax, can I still get something from cello?
Why would one choose this:<p><pre><code> var int_item = $(Int, 5);
</code></pre>
over this:<p><pre><code> int int_item = 5;
</code></pre>
What am I missing?
loving it, definitely
I was playing with these sort of things these months and eventually I was ending with something similar, but that is far away what I was doing.
I think I will contribute to this lib if i can instead of continuing my shit :)
i hope this get more and more popular.. in a way that the next natural step would be implementing a special parser for it in GCC and Clang (as some sort of C subset)..<p>totally awesome!
"Constructors/Destructors aid memory management"<p>Does it do RAII? Really, calling destructors implicitly on auto variables on scope exit is the main thing missing in C here.