Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

My Google SoC project was writing a c++ bindings generator for Common Lisp: https://lwn.net/Articles/147676/ (In my head this was ten years ago, but apparently it‘s nearing 17. Shit I’m getting old.)

C isn’t ideal, but it’s actually not so bad and it could be worse (it could be C++). Yes parsing C is non-trivial, but that’s true of every language. These days you have libclang and a dozen other decent C parsers. Back in my day we had to use a hacked up version of GCC (and we liked it).

Also, C doesn’t have a standard ABI, but every real world platform defines a C ABI. And it’s pretty simple. Meanwhile trying to handle all of the cases of C++ vtables took up weeks of my life (and I ended up shipping without fully supporting multiple inheritance, which is stupid anyway).

The bigger problem for writing FFIs is, in my opinion, memory management. That’s where it gets really hard to paper over for the binding user that you’re talking to C.



> Yes parsing C is non-trivial, but that’s true of every language.

Have you heard of our lord and savior LISP?


You can’t even tokenize Common Lisp without being able to execute Common Lisp (read macros). :D


Probably?

> My Google SoC project was writing a c++ bindings generator for Common Lisp


> Yes parsing C is non-trivial, but that’s true of every language.

Not sure about this. C is ambiguous without a symbol table, and the preprocessor is necessary for populating that. Parsing against all of the correct headers (e.g. libc, kernel headers) with correct macro values is tough.

Most languages' concrete syntax treat type references in an unambiguous way (e.g. separating them from values with `:`), which is just much easier.


SoC = Summer of Code, not System on Chip for anyone else who was confused at first :)


I thought they meant Security Operations Center


The O would be capitalized if that were so. ;)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: