Clasp is not quite the same, but it can work seamlessly, and compiles to machine code using an LLVM backend [1].
It was created to facilitate using all of the scientific libs in C++ by a chemistry professor for the creation of molecules [2]. It's a big codebase. I'll have to look at LispY C, since on first impression it seems smaller, and I like C!
Embeddable Common-Lisp[1] compiles Lisp to C and hooks to the compiler on the host system (generating and building code during the runtime is also possible). Moreover it's a full implementation of the Common Lisp and has a bytecode compiler/interpreter which may freely interop with the C/C++ code.
C-Mera[0] is also worth looking at. It's a Lisp-to-C-like source-to-source compiler. They're doing pretty neat stuff with that wrt. high-performance graphics[1]. On this year's European Lisp Symposium there was a demonstration of using this to generate and simultaneously test a graphics filter on many different architectures with many different optimizations to determine which works best on what. The video of the talk should be available next week.
Wow, that does look interesting, and one file has over 16K LOC, when compared with the <1.5K LOC of the OP's Lispy C. Both seem to let you code in SEXPRs in a very C-looking style.
Others are raising Lisp to C solutions like ECL, but I have not really seen the C output of ECL, and you program ECL in Lisp. With C-Mera or Lispy C you are sort of writing in C with parentheses. At least that is how it looks to me. I have used Gambit-c and CHICKEN scheme before without really touching the C they output.
Some Lisps? Almost all Common Lisps compile to native machine code. Which is why CL programs tend to run orders of magnitude faster than e.g. Python programs. (But they're still typically slower than C because of runtime memory allocation and typetag checking.)
Chez Scheme (the compiled version vs. Petite Chez) figures high on those lists, and it was just opensourced by Cisco. I used to use Gambit-C, and I still like it, but Chez is fast.
I am playing with Eduardo Cavazos's libraries with Chez [1], and particularly the port of xspringies. Great fun considering as he points out that the mass-spring calcs are all taking place in scheme. It runs fine on my 2-3 year old notebook.
C was a third language for me in the day, and I like Lisps, so this Lispy-C thing is going to eat my afternoon up!
Fine! To generate the C code using Lisp syntax - it's not such bad idea, the C preprocessor is awful. A few years ago, for this purpose, I wrote the yupp preprocessor which use similar syntax, but yupp allows to inject the code in functional style into the source code on C.
I feel like besides powerful macro generation, the other big selling point of a lisp is that you can dynamically generate code at runtime, either by providing hooks into the compiler itself or by running the generated code through an interpreter. This project doesn't seem to do that at all. Does anyone know of any similar projects that do?
I never published it, but I wrote FFI bindings from common-lisp to the tinycc library, and it could generate and compile C code at runtime without having to shell out to a C compiler. It was really more of a toy than anything else, though it was slightly useful for things like basic system calls with complicated structs.
I'm not sure about where you see the difference between those "selling points" - Lisp macros are the very advanced facility for runtime code-generation and compile-time computing. It's not just about expanding syntactic shortcuts - Lisps give you full power of the language runtime and compiler to be used at compile-time.
I'm currently writing a library/book dedicated to the subject, including compile time state, compile time I/0, and a compile time test framework in 9 lines of code!
Tests are specified as part of the definition, run at compile time, and if they fail no executable is produced.
I understand that macros are both the mechanism to generate code at compile-time as well as for generating code at runtime. But it doesn't look like the linked project does the latter. In fact, there are mentions in the README that indicate that there is no runtime for LISP/c at all:
> The way that LISP/c works is sort of tricky. It utilizes a lot of string manipulation and interpretation. It doesn't need to be insanely fast, though, because it's just dealing with code; the compiled result will not suffer from any slowness.
In other words, it seems that this project just allows you to generate C code from a LISP-like syntax, but doesn't allow you to `eval` during the execution of the resulting C program. There is no runtime representation of code as data as with other lisps.
Not a 1=1 match, but you might also want to check https://github.com/aoh/owl-lisp if you need a Lisp that produces C code to gain the optimization goodies of different C compilers.
> the only difference between a struct and a class
In C++ land, this would be true.
C doesn't let you write methods within structs. C structs don't even have inheritance. No virtual table is generated. There is no single-dispatch mechanism.
I think VLISP is, as well. VLISP (not the French one from the 80s, the other one, though the French one was interesting in its own right [1]), was a verified Scheme implementation written in a verified version of Pre-Scheme. Sweet research project, but I haven't seen any public releases of it :/
VLISP was a precursor to Le-Lisp [2], which was massively popular and influential in Europe, and could run faster on commodity hardware than Lisp Machine Lisp on the Symbolics 3600.
[2]: http://lelisp.org/ (under construction, but with some useful links for the time being).
France was actually a hotbed of Lisp across the pond and, along with the UK, pretty invested in a European standard for Lisp, first EuLisp (which was an excellent language but somehow flopped unfortunately) and ISLISP (an ISO standard that's not so excellent -- basically a crippled version of Common Lisp -- and also pretty much flopped). I've been in talks with some of the Le-Lisp guys about the possibility of open-sourcing Le-Lisp now that it's no longer commercially viable -- fingers crossed! :)
P.S., if anyone from INRIA happens to be reading this: pretty please?? Jérôme agrees! :)
It was created to facilitate using all of the scientific libs in C++ by a chemistry professor for the creation of molecules [2]. It's a big codebase. I'll have to look at LispY C, since on first impression it seems smaller, and I like C!
[1] https://github.com/drmeister/clasp [2] https://github.com/drmeister/clasp