Cello: Higher level programming in C

by mntmn • 13 years ago

535 157 13 years ago

dcope• 13 years ago

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.

McUsr2• 13 years ago

I have just glimpsed at the doc, but it sure looks exciting. Thanks!

I love the idea!

Hopefully, I can manage to make it work with CoreFoundation in OS X.

Maybe I'll end up with CoreFoundation+ :)

diaz• 13 years ago

I just checked the source and... My god, it's beatifull :P.

Gonna read some more when I have time, I could learn something from this.

kragen4• 13 years ago

No, dear God, no. Please, no.

McUsr2• 13 years ago

I see you believe in my axiom: "It can always get worse". :D

ambrop7• 13 years ago

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?

tehwalrus• 13 years ago

check out the Prelude.h file on their github - it's essentially all implemented as preprocessor nameswaps and macros. It's quite clever actually!

koenigdavidmj2• 13 years ago

$ is a valid function name according to gcc. try/catch/foreach are #define'd as part of it. As an example, foreach is defined to a for loop over an iterator, which is any Cello class with a couple of functions defined.

maaku• 13 years ago

I'm guessing that the GNU99 qualification is important. GCC supports most if not all of the claimed features, or at least the low-level constructs required to create them.

mcpherrinm• 13 years ago

  #define foreach(x, xs) \
    for(var x = iter_start(xs); x = iter_next(xs); x != iter_end(xs))

It's all C: http://libcello.org/documentation/hacking

kragen4• 13 years ago

Imagine what happens when someone says

    foreach(x, get_next(queue)) f(x);

To solve this problem, with GCC, you have the option of defining foreach as

    { typeof (xs) _xs = xs; \
      for (var x = iter_start(_xs); x = iter_next(_xs); x != iter_end(_xs))

but then you need a corresponding endforeach to apply the matching }. If you just leave off the opening {, then you end up with a mysterious compile error on

    if (ready(queue)) foreach(x, get_next(queue)) f(x);

since the declaration of _xs is not a statement.

And this kind of thing is why a "macro system" means something very different in C and in Lisp, and why Brad Cox wrote a compiler in 1983 instead of a macro library.

Demiurge3• 13 years ago

You can do pretty much anything if you rely on preprocessor. The $ is a define: http://libcello.org/documentation/hacking

JoachimSchipper2• 13 years ago

Pretty cool, even if I don't want to see the compiler warnings. ;-)

In the same vein, but more C-like: http://p99.gforge.inria.fr/p99-html/.

Demiurge3• 13 years ago

This looks nice. A lightweight macro for Class, that is just a struct with function pointers, and I will use it over c++ :)

breckinloggins3• 13 years ago

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.

eblume• 13 years ago

I wrote a similarly-themed (although much less complete and much less useful) package for Go called 'Proto' which essentially sidesteps the static typechecker by mapping the 'base useful type' to `interface{}`, which is philosophically similar to `void *`.

I personally have no problem with it (other than the syntax needed to unbox/rebox values). I find that having the freedom to use a type system or not a very compelling feature in a language.

That being said, I understand why it might sit very poorly with some.

bjeanes• 13 years ago

Though in Go, you can always use reflection to get back the concrete type in an `interface{}` type. In C, `void *` is pretty much all you get. This causes far more subtle bugs, IMO.

Source: someone who hasn't done much C and only a little bit of Go. So take it with a grain of salt.

optymizer• 13 years ago

random question: doesn't ObjC define 'nil' (or self?) as 'void*'? I did some ObjC coding 2 years ago and I remember seeing something like this and thinking: oh boy.

rdouble• 13 years ago

Nil is (void *)0.

geon• 13 years ago

The ’id’ type is a void *. It is used extensively, whenever there are multiple possible return types. Even where inheritence could have been used to make it more speciffic.

For example, ’alloc’ and all ’init’ returns it.

mjn• 13 years ago

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.

JonFish85• 13 years ago

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.

yk• 13 years ago

I think quite similar about this, its in some way like training wheels on a motorcycle.

But I think there could be quite interesting uses for Cello, namely you do your prototyping with it and then you trow out the library and refactor the code to pure C.

georgeg• 13 years ago

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.

Demiurge3• 13 years ago

I think it's more useful than D though, because I can just add a header file to an old C project and make things better and still have things interoperate.

halayli• 13 years ago

Just use C++11.

deletes• 13 years ago

Does it have inheritance and polymorphism?

scrumper• 13 years ago

From the page: "Cello isn't about Object Orientation in C".

So no. It isn't object oriented, but it does some nice-looking things with structured types.

koenigdavidmj2• 13 years ago

It seems to be targeting the same market as Go or Haskell OO more than that of C++. A class in this model basically means 'definitions for a set of methods on this type', so it's more like what you understand as an interface.

For example, there's a "show" class that converts your object into a string. Any object that implements the necessary methods can thus be printed.

Another example is an iterator class. If you implement a couple of methods (move the cursor to the start, increment the cursor, see if the cursor is at the end, and get the currently pointed-at item), then you can be iterated over by a foreach loop.

Unlike Go, though, with Cello you seem to need to explicitly specify the functions used to implement each class.

chongli3• 13 years ago

Haskell OO

Huh? Haskell is not OO by any means.

cad• 13 years ago

Why, why, why didn't I break his legs!

breckinloggins3• 13 years ago

I want to make a few observations about this, and why I found it seemingly less "hacky" than other such attempts:

- 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.

- 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.

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.

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.

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?

bodski4• 13 years ago

Steve Yegge at Google is/was involved in a project called 'Grok' which sounds pretty similar to that. I really hope it catches on also.

http://bsumm.net/2012/08/11/steve-yegge-and-grok.html

http://www.youtube.com/watch?v=KTJs-0EInW8

HN discussion: https://news.ycombinator.com/item?id=4371267

breckinloggins3• 13 years ago

Thanks! I knew I had read something that was along these lines and that was it. I've been thinking about this problem for years. Perhaps it's time I worked on it myself.

williamcotton13• 13 years ago

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.

Well maybe if we stopped using ASCII files as our source code and used a richer type of document we could start to make some improvements!

What kind of rich document? Well, what about HTML? Did you know you can even embed interactive elements in such documents? What if we started embedding our source code and editors in our documents instead of the other way around? The whole model is inverted, but mainly for historical reasons, because you know, in 1979 all we had was VT100 to interface with our machines... it's like we never moved on... why is my "code" a splattering of ASCII files in a directory? A package definition, tests, dotfiles for this and for that... ship the editor, the tests, the docs, the examples, and the source ALL as one document!

gertef2• 13 years ago

HTML is ASCII.

jacobwcarlson• 13 years ago

What if we started embedding our source code and editors in our documents instead of the other way around?

We all agreed that was a bad idea: http://en.wikipedia.org/wiki/Opendoc

t1m2• 13 years ago

That may have been the case in 1979, but in 1980, we got Smalltalk. This environment was (almost) completely without the concept of a file. Code was stored in a persistent 'image', like everything else, and was accessible through normal object based data structures. This, and the fact that all of the source code for the system was immediately available, made it extremely easy to build and extend language level tools like browsers and debuggers.

I would say the downside of this 'rich' environment is that your tools tend to become language dependent. Early Smalltalk code versioning tools were fairly easy to build (I'm guessing), but would definitely be Smalltalk centred. The unfortunate advantage of an ASCII text file is that it very difficult to have more than one interpretation of it's non-existent meta-data.

orangeduck• 13 years ago

Author here. Yeah the syntax looks much better with correct highlighting. I've provided a custom definition for Notepad++ on the repo - and of course there is the definition used on the website too.

I'm also a big fan of DSLs and would love see some of the things you mention. My next (fun) big project is actually not so far from the same lines ;)

Many thanks to everyone for the kind comments! It really is encouraging. :)

mtdewcmu2• 13 years ago

If you would like to take on something that is genuinely lacking from C, try creating something equivalent to C++ templates for C. I'm not sure that it can be usefully accomplished using only the C preprocessor. The C preprocessor is extremely underpowered. So it might require its own preprocessor.

I wouldn't make them exactly like C++ templates. I'd just focus on the useful things that you can't currently do in C, like write a qsort()-equivalent that doesn't suffer the performance penalty of callbacks. You can almost get there with macros, but not quite -- it would be ridiculously ugly at best.

vilya• 13 years ago

This sounds like a similar idea to JetBrains' MPS: http://www.jetbrains.com/mps/

The idea with that was that you could provide a structured description of a mini-language and it would be sufficient to generate not only a parser, but also a syntax-highlighting IDE with smart code completion, debugging and other neat features. It looks like they're still developing it too, which is a nice surprise: back when I was still interested in it, it never seemed to have taken off.

bodski4• 13 years ago

MPS sounds more like some kind of equivalent to Xtext, i.e. for ease of producing and and hosting DSLs. Tools like Xtext and MPS actually tie you in to their host environments (Eclipse and IntelliJ respectively).

What I took GP to mean, and indeed what Yegge's Grok appears to aim for, is the need for a universal modelling framework 'standard' for languages, tools and runtimes. Some kind of equivalent to LLVM but in the 'other direction' for modelling language semantics instead of code. Once a tool (e.g. editor) implements that standard it is able to 'plug in' to any tooling that also implements the standard. Potentially eliminating huge amounts of duplicated effort for tool makers etc.

conradev• 13 years ago

libclang supports this and a lot more advanced functionality, but only works for languages supported by Clang:

http://clang.llvm.org/doxygen/group__CINDEX.html

(It is what Xcode uses underneath, a C API that any IDE or dynamic language module could take advantage of)

claudiug• 13 years ago

create a webframework now like rails/django and you will have some marketing :P

guard-of-terra• 13 years ago

They should neither use C++ keywords nor invent parallel terms (real vs float) in order this to fly.

makmanalp• 13 years ago

Slightly related tangent:

I'm looking for standards / set of libraries / best practices for "modern" C development, but I've yet to find a comprehensive resource.

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.

I'd be okay with a small, well written example library too. Does anyone happen to know something like this?

edit: Ah, sorry if I misled you, that was just an example of the kind of tips and pointers I was looking for. Or weird bits like the linux kernel list_head. http://kernelnewbies.org/FAQ/LinkedLists 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.

ldite• 13 years ago

Stuff like typedefing a manual fixed sized int type to be cross-platform compatible

If you're lucky enough to be able to rely on C99: https://en.wikipedia.org/wiki/Stdint.h#Fixed-width_integer_t...

kqr2• 13 years ago

I like to recommend C Interfaces & Implementations

http://www.amazon.com/Interfaces-Implementations-Techniques-...

It uses Donald Knuth's literate programming which takes getting used to, however, it's a great case study of how to make a good library.

There is a new book on "21st Century C" which I haven't read. It has mixed reviews, however.

http://www.amazon.com/21st-Century-Tips-New-School/dp/144932...

VMG• 13 years ago

As somebody with the same query, let me hop on - how does "Learn C the hard way" fare? I've got it mentally bookmarked the for next time I touch C code.

falcolas• 13 years ago

Pretty good, in my opinion. It's fairly comprehensive, and focuses a lot of time and effort into pointing out why things in C break and how to be preemptive about fixing them.

A fair bit of discussion around your standard exploits as well.

JoachimSchipper2• 13 years ago

I'm a fan of BSD sys/queue.h and especially sys/tree.h; they are liberally-licensed header-only implementations of various kinds of linked lists resp. binary trees.

mtdewcmu2• 13 years ago

You may want to study the source code of a well-written, modern C project like git: https://github.com/git/git

The fixed-size int finally got a permanent solution: #include <stdint.h>

If you are targeting autoconf/automake as your build system, that has a lot of built-in solutions to portability issues, like defining macros. It's not easy to learn, and I don't pretend to know it well, but when I'm compiling someone else's project, I'm always happy to see a configure script.

The gtk project's libglib is a pretty comprehensive library of C data structures. The Apache Portable Runtime serves a similar purpose: http://en.wikipedia.org/wiki/Apache_Portable_Runtime

What I find annoying about libraries like glib is that they tend to impose their own style on your project by using their own typedef'ed types and such.

If you don't mind it, you can cobble together your own data structures from various open-source projects. Judy arrays are pretty fast, and you can use them in a variety of ways. Searching google for "c hash table" came up with a lot of excellent results, so try googling whatever data structure or algorithm you need, and chances are, you'll find something.

bjourne• 13 years ago

Glib/GObject is pretty good and seems to be what you're looking for: https://developer.gnome.org/glib/2.37/ It's not tied to the GNOME platform at all but rather contains building blocks such as hash maps, linked and array lists, heap allocators, string manipulation functions and so on. Personally, I find some parts of GObject to be over engineered and distasteful but most of it is solid utility.

Then you have https://wiki.gnome.org/Vala which is a whole new language built on top of C + Glib/Object whose main selling point is that it compiles to, and is totally compatible with, plain C code.

Do keep in mind that all of this, Glib, Vala, Cello and other "make C more like a high-level language" are basically hacks to workaround the fact that C is a very low-level language and lacks many powerful features. I believe one is much more productive using Glib + C than just plain C, but you are still less productive than if you had choosen a modern language in the first place.

robododo• 13 years ago

It looks pretty, but I'm already having nightmares about stepping through this in a debugger.

anuraj• 13 years ago

Well - this looks more PHP now - given that PHP interpreter is actually a shell on native C - I think it already achieves this.

sovande• 13 years ago

Not thread safe. For instance the exception stack is global.

al3xbio• 13 years ago

Also see https://github.com/orangeduck/libCello/issues/35

brambit• 13 years ago

Use macros?

jacquesm• 13 years ago

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.

ExpiredLink7• 13 years ago

People interested in real-world high(er)-level C programming should take a look at this book, "especially the class methodology in Chapter 4": http://www.duckware.com/bugfreec/index.html

Side note: this book would certainly be down-voted on r/programming but I expect more grown-ups here.

da02• 13 years ago

(I'm not on r/programming.) Can you go into specifics as to why they would downvote it?

ExpiredLink7• 13 years ago

Microsoft used this style of programming.

ExpiredLink7• 13 years ago

Another classic: "Writing Solid Code" by Steve Maguire

http://www.amazon.com/dp/1556155514

eliasmacpherson• 13 years ago

Excellent, I hope the data hiding techniques are what I'm looking for. I was a little disappointed by this: https://code.google.com/p/ooc/downloads/detail?name=ooc.pdf

dubcanada• 13 years ago

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?

egonschiele• 13 years ago

Yes.

0x092• 13 years ago

You can write regular C GTK+ code side by side with it, but you would need a wrapper in order to use most of the constructs with GTK+, or anything else not written with Cello's type system in mind (e.g. var w = $(GTKWidget) would not work for multiple reasons).

oscargrouch• 13 years ago

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)..

totally awesome!

jnbiche2• 13 years ago

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.

jnbiche2• 13 years ago

To follow up on my threadsafe remark above, I should add that it's only the Exceptions that don't appear threadsafe, and it looks like that's fixable.

dsego• 13 years ago

If there is already new syntax, why not just make a completely new language that compiles to C, like vala or something similar?

smegel• 13 years ago

"Constructors/Destructors aid memory management"

Does it do RAII? Really, calling destructors implicitly on auto variables on scope exit is the main thing missing in C here.

ExpiredLink7• 13 years ago

... and cannot be implemented in pure C.

mortdeus• 13 years ago

Eww

hugs• 13 years ago

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:

$ gcc -lCello -std=c99 -fnested-functions example.c -o example

Hope this helps someone!

akadien3• 13 years ago

Harrumph. Our http://github.com/redjack/libcork.git library is better.

nkurz• 13 years ago

Took a look: interesting library. Documentation looks good. When following the link to 'readthedocs.org', it took me to http://libcork.readthedocs.org/en/0.10.0/ which has a message on top that says it's not the newest version. Editing the URL gets me to http://libcork.readthedocs.org/en/0.11.0/. Not sure where it should go, but might be worth checking. Thanks!

akadien3• 13 years ago

Thanks. We'll fix the link.

akadien3• 13 years ago

I guess my tongue-in-cheek plug for our C library was misinterpreted. I really didn't mean to ding Cello, just put ours out there, too.

ExpiredLink7• 13 years ago

Is it used in real-world projects except your own?

eonil• 13 years ago

Interesting at first, but lack of static type-check (or notation) voids everything.

guilloche• 13 years ago

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?

I am not a fan for C++ syntax, can I still get something from cello?

sspiff• 13 years ago

The fact that this uses "void *" as a universal type makes me somewhat reluctant to try this out.

jlebrech• 13 years ago

Someone build an nginx (openresty?) module with this.

popee• 13 years ago

Chello is nice proof of concept, but personally i'd like to see only one or two changes to C standard:

1. sizeof(function) -> would give user ability to copy functions around.

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.

Another interesting thing to do would be to, somehow, eliminate function pointers with _Func.

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 ???).

_Func int example_prototype(int i, int j) {

  return i + j;

}

And then do something like:

example_prototype func0;

memcpy(&func0, example_prototype, sizeof(example_prototype));

struct prologue_t *p_ptr = &func0;

p_ptr->sp = 0xdeedbeef; // Or some address that is used as stack

z = func0(5, 6)

So, what do you thing how hard would it be to implement something like that?

groue• 13 years ago

Do you know C blocks ?http://en.wikipedia.org/wiki/Blocks_(C_language_extension)

ilitirit• 13 years ago

Why would one choose this:

  var int_item = $(Int, 5);

over this:

  int int_item = 5;

What am I missing?

pmelendez• 13 years ago

Well with the var option you do something like this:

var item = $(Int, 5); ... code ... item = $(String, "5");

Not that you want to do that all the time but it is a way to implement duck typing

JackdawX• 13 years ago

A better example for duck typing would be something like:

var my_func(var int_or_string, var int_or_obj) { ... return int_or_string_result; }

Simplifies certain operations, complicates debugging. Great for small scripts though.

mogui• 13 years ago

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 :)

Cello: Higher level programming in C

Related Stories