from Hacker News

Cello – High Level C

by thisisastopsign on 1/20/20, 10:16 PM with 77 comments

  • by kazinator on 1/21/20, 2:12 AM

    The strategy in the GC for determining the stack top for hunting GC roots will not work on all architectures.

    On aaarch-64, the address of a local dummy variable may be above a register save area in the stack frame, and thus the scan will miss some GC roots.

    In TXR Lisp, I used to use a hacked constant on aarch64: STACK_TOP_EXTRA_WORDS. It wasn't large enough to straddle the area, and so operation on aarch64 was unreliable.

    http://www.kylheku.com/cgit/txr/commit/?id=3aa731546c4691fac...

    A good stack-top-getting trick occurred to me: call alloca for a small amount of memory and use that address. It has to be below everything; alloca cannot start allocating above some register save area in the frame, because then it would collide with it; alloca has not know the real stack top and work from there.

    Since we need to scan registers, we use alloca for the size of the register file (e.g. setjmp jmp_buf), and put that there: kill two birds with one stone.

    http://www.kylheku.com/cgit/txr/commit/?id=7d5f0b7e3613f8e8b...

  • by aerovistae on 1/20/20, 10:48 PM

    Seen this posted here years ago. Now as then, my gut feeling is that anyone doing serious work in C would never use something like this-- I feel like the fine grained low level control is exactly the reason they chose C in the first place, and they're not looking to escape from it or they would just choose a different language.

  • by analog31 on 1/21/20, 12:45 AM

    This is just an amusing aside: C is the lowest level of an actual cello. ;-)

  • by drongoking on 1/21/20, 1:14 AM

    Isn't this sort of what Glib is getting at? Bringing higher level data structures and capabilities (extendable arrays, hash tables, heaps, etc.) into C.

    https://developer.gnome.org/glib/stable/glib-data-types.html

    You don't get Cello's macros, and it uses reference counting instead of invisible garbage collection, but you get a lot of fun high-level capabilities.

  • by winrid on 1/20/20, 11:24 PM

    There was a snippet I saw a while ago where someone made C look like Java for a joke, using macros. I wish I could find it to share here, it's great.

  • by gok on 1/20/20, 10:48 PM

  • by kazinator on 1/21/20, 2:15 AM

    I'm left wondering about the iteration example that is also quoted in the home page:

    https://github.com/orangeduck/Cello/blob/master/examples/ite...

    Okay, so the vector is garbage-collectable once the function terminates ... but it has references to stack-allocated integers i0, i1 and i2. That leaves me wondering: won't the GC walk these and trample on stack memory that has been deallocated/reused.

    (Maybe those integer values have a tag right in the val pointer that gets the GC to avoid dereferencing them.)

  • by noncoml on 1/20/20, 11:29 PM

    Just my opinion, don't mean to be inflammatory, but if the user has to know and manually manage stack vs heap objects, then I wouldn't call it "High Level" language.

  • by rs23296008n1 on 1/21/20, 4:55 AM

    Didn't C++ start out as a set of hacks on C? Fairly sure it was originally a preprocess stage ahead of an ordinary c compiler.

    Raises the question of how usefully far you can make C twist using macros / preprocessor.

    Candidates like Forth or Lisp seem possible. A few weekends at most. Might need to take a few liberties.

    Python... Perhaps if you implement a less dynamic subset? Duck typing may trip you up. To what extent?

    What about Elixir?

  • by scoutt on 1/21/20, 9:38 AM

    Thanks. I didn't know about this library. Interesting, but perhaps I am missing something... about stack "allocation":

      var i0 = $(Int, 5);
    vs

      int i0[5];
    In both cases it doesn't need GC. What would be the reasons for redefining it? I wonder how it couples with local static variables.

  • by shmerl on 1/20/20, 11:50 PM

    Is it using macros to achieve that?

  • by self_awareness on 1/21/20, 12:34 PM

    For a different take for "better C", try Zig language, it looks pretty cool.

    https://ziglang.org/

  • by loeg on 1/21/20, 1:20 AM

    This gets reposted every couple years and it's still bad for all of the same reasons.

    It's not higher level than C in the sense that you get any additional safety guarantees or real beneficial abstractions. If you are fine without the safety but want abstractions, use C++. If you want safety and abstractions, use Rust or Go or Zig. If you really want a transpile-to-C language, you've got Nim.

    Finally, it's not good at being C; everything it does is poor practice and should be quickly recognized as such by experienced C developers, IMO. It's got no developer community and no real-world production consumers.

  • by h0bzii on 1/20/20, 11:01 PM

    What type of sorcery is this?

  • by FpUser on 1/20/20, 11:13 PM

    This is great. It made me smile.

  • by tuczi on 1/20/20, 10:48 PM

    Why not just C++?

  • by einpoklum on 1/20/20, 11:54 PM

    This isn't a library, it's a sort-of-a-modification of C, it seems.

    Well, for a non-C language with high-level abstractions that lets me use C code relatively seamlessly - I'm content with C++. Many complain about its complexity, but you can actually avoid a lot of that complexity in _your_ code using facilities with complex implementation but relatively easy use.

  • by reanimus on 1/21/20, 1:37 AM

    Looks interesting, but I can't help but notice they're distributing their source tarball via that site, and it doesn't have HTTPS. I don't understand why projects don't have SSL certs these days, especially considering Let's Encrypt has automated it all and made it free.