
Cello – A library that brings higher level programming to C - dlsym
http://libcello.org/
======
int_19h
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:

    
    
        #define alloc_stack(T) ((struct T*)header_init( \
          (char[sizeof(struct Header) + sizeof(struct T)]){0}, T, AllocStack))
    

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.

~~~
ant6n
Apparently ARM allows unaligned loads now (permitted in ARMv6, default in
ARMv7). There seem to be some instructions that don't support it, like STM.
Also, afaik code needs to be aligned properly, and function pointers need to
be aligned properly lest you will switch between arm and thumb mode.
Apparently you can tell the ARM compiler to assume all memory accesses are
unaligned.

Under ARMv8, I think alignment is less of an issue.

[http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....](http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15414.html)

------
krat0sprakhar
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:
[https://news.ycombinator.com/item?id=8800575](https://news.ycombinator.com/item?id=8800575)

Another previous discussion:
[https://news.ycombinator.com/item?id=6047576](https://news.ycombinator.com/item?id=6047576)

------
AnimalMuppet
> Can it be used in Production?

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

Wow. Straight talk instead of salesmanship. High marks for that.

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

~~~
simias
I'm not super familiar with Cello (and I'm not sure I get the point of it
overall, are there that many platforms left that you can target from C but not
C++?) but in its defense it does seem to implement fat pointers and runtime
checks to have a degree of type safety. Not sure how thorough it is but it's
not just decaying everything to void pointers behind the scenes.

It's a pretty clever hack though, like using setjmp for exception handling.
I'm pretty sure I'd never want to use that in production anywhere but it was
probably fun to implement.

~~~
crazyhatfish
Do you use Python in production? It uses setjmp for its exception handling.

------
wyc
The style reminds me of some J implementations!

    
    
       #define DO(n,x) {I i=0,_n=(n);for(;i<_n;++i){x;}}
    

[http://code.jsoftware.com/wiki/Essays/Incunabulum](http://code.jsoftware.com/wiki/Essays/Incunabulum)

~~~
jnordwick
I think Arthur Whitney's (in)famous code makes its way to HN about once a
year.

~~~
agumonkey
#A=As #I=it #S=sh #o=o #u=uld

A I Sou

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

------
wybiral
What features make it "higher level"? It looks like syntactic sugar on C code
without any real improvements (aside from GC).

~~~
shakna
I've used Cello for a few side projects, and it doesn't even really feel like
C in the end.

Just a few off the top of my head:

* No need to specify type. Use var.

* Simpler for loops

* Inbuilt types for Hash Tables

* File types, making file reading much easier

* Function types, making it easier to pass functions around

* Doctype access

* Threads & Mutexes

* Format strings

* GC (with ability to turn C-types into Cello-types for GCing.)

It _is_ fundamentally syntax-sugar, but enough that what you end up with
doesn't necessarily _look_ like C at the end.

    
    
        with(f in new(File, $S("test.txt"), $S("r"))) {
          var k = new(String); resize(k, 100);
          var v = new(Int, $I(0));
          foreach (i in range($I(2))) {
            scan_from(f, 0, "%$ is %$ ", k, v);
            show(k); show(v);
          }
        }
    

(From: [http://libcello.org/learn/file](http://libcello.org/learn/file))

~~~
ckastner
> * No need to specify type. Use var.

I see types everywhere; they appear to just have been moved from the left-hand
side to the right-hand side? eg:

    
    
      var i0 = $(Int, 5);
      var items = new(Array, Int, i0, i1, i2);

~~~
shakna
Mmm, kinda.

    
    
        var i0 = $(Int, 5);
        i0 = $(String, "Hello");
    

Perfectly valid.

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

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

~~~
stephen_g
I'm going to say you're right, given one of the first declarations is

    
    
        typedef void* var;
    

Cello is extremely impressive and could be fun for hobby projects, but for
something you'd actually want to use on a real product you'd be better off
just creating a new language (it could compile down to C even, like Vala did).

~~~
dingdingdang
>> (it could compile down to C even, like Vala did).

Nim is another take on that particular strategy.

~~~
cvwright
Another recent one is Ivory. [http://ivorylang.org](http://ivorylang.org)

------
amaks
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
([https://msdn.microsoft.com/en-
us/library/windows/hardware/ff...](https://msdn.microsoft.com/en-
us/library/windows/hardware/ff559740\(v=vs.85\).aspx),
[https://view.officeapps.live.com/op/view.aspx?src=http://dow...](https://view.officeapps.live.com/op/view.aspx?src=http://download.microsoft.com/download/5/b/5/5b5bec17-ea71-4653-9539-204a672f11cf/KMcode.doc)).
Libraries like this obfuscate source code.

~~~
95014_refugee
A problem with C in modern usage is that many people believe this to be more
the case than is warranted.

------
zaiste
Here's the author of Cello talking about the project at PolyConf in 2015:
[https://www.youtube.com/watch?v=bVxfwsgO00o](https://www.youtube.com/watch?v=bVxfwsgO00o)

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

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

~~~
camus2
> There are not many reasons to use C nowadays beside performance.

portability? stable ABI? ... writing something in C make it easy for any other
higher level language to link to it. That's why we're not done with C, at all
... it's basically the only serious language out there used to share code
among every possible platform or language. Even C++ which is a bit safer in
practice is harder to link.

I just wished C was a bit safer by default (arrays with bound checking,...)

~~~
maccard
> Even C++ which is a bit safer in practice is harder to link.

Not to go down the C++ evangelist route, but if you want to write libraries in
C++ to use with other high level languages, you can wrap the headers in extern
"C", and still write C++ as normal in your own code.

~~~
ziotom78
…unless your library exposes classes/templates, which is probably what the
majority of C++ libraries do (e.g., wxWidgets, Qt, Boost, etc.). In this case,
creating C bindings is a real pain.

------
hydrocat
Isn't this something similar to vala ?

~~~
chme
No not really.

Vala has an own seperate transpiler that generates C code from Vala code.

Cello uses the normal C preprocessor to generate C code.

~~~
camus2
Actually Vala generates GObject code, which fundamentally has its own "type
system" and uses reference counting.

------
ndesaulniers
Why not just use C++?

~~~
feelix
That's like saying "Why not just use lisp?" to a python programmer. They're
entirely separate languages (albeit it they do share some commonalities, but
not as many as you might think).

C is my main language and I dabble in C++. I really dislike C++. I love C. I
welcome any efforts to add a bit of higher level functionality to C. I have no
desire (ever) to switch to C++.

~~~
loeg
C programmer here. Cello isn't really C. So as long as you're using something
that isn't quite C, and you want an object model, I think "why not C++?" is a
reasonable question.

~~~
webkike
Looks like C to be. Just some macros and function calls.

~~~
khedoros1
If someone showed me a sample of the code, out of context, I wouldn't have
guessed it was C. Maybe Javascript (with the "var" declarations).

------
r00t-
Either the examples are terrible or the library is. I'm leaning towards the
latter.

