LispY C | Hacker News Reader

LispY C

github.com

184 pointssigna1144 comments

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!

[1] https://github.com/drmeister/clasp [2] https://github.com/drmeister/clasp

Clasp is an implementation of Common Lisp, a standard language and not a self-designed lisp as in the case of Lisp/C.

Thanks for the clarification. I am going to dig in and have a look.

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.

https://common-lisp.net/project/ecl/

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.

[0] - https://github.com/kiselgra/c-mera

[1] - https://github.com/kiselgra/cm-fop

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.

> Because LISP is expressive and C is fast and I wanted the best of both worlds is the short answer.

I'm not sure how well known it is, but some Lisps can be statically compiled to machine code.

But one thing I've wondered about is how good can it get? Are there any benchmarks for Lisp vs. C?

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

For example: https://www.call-cc.org/

That's a full Scheme that compiles to C. It's quite nice, too!

It's a fine compiler for sure, but have you seen the generated C output? It's based on Henry Baker's Cheney-on-the-MTA compilation strategy.

https://wiki.call-cc.org/chicken-compilation-process

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

Talking about speed, someone put this online http://www.nexoid.at/tmp/scheme-benchmark-r7rs.html

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.

It is and regularly way above the others. I had to hold on my fanaticism.

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!

[1] https://github.com/dharmatech?tab=repositories

That would be ecraven (who hangs out in #scheme on Freenode). See also: https://github.com/ecraven/r7rs-benchmarks

> The C Programming Language by Brian W. Kernighan

An interesting way to cite K&R.

Where-as I typically cite it in shorthand as "K&R", dropping "The C Programming Language" altogether.

Looks a lot like this:

http://voodoo-slide.blogspot.se/2010/01/amplifying-c.html?m=...

https://github.com/deplinenoise/c-amplify

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.

https://github.com/in4lio/yupp/

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.

  {define
    "list#"
    permutations
    [|l|
     (if (null? l)
       ['()]
       [{let permutations ((l l))
          (if (null? l)
              [(list '())]
              [(flatmap [|x| (map [|y| (cons x y)]
                                  (permutations (remove x l)))]
                        l)])}])]
  ;;; tests
  (satisfies?
   permutations
   '(
     (() ())
     ((1) ((1)))
     ((1 2) ((1 2)
             (2 1)))
     ((1 2 3) ((1 2 3)
               (1 3 2)
               (2 1 3)
               (2 3 1)
               (3 1 2)
               (3 2 1)))
     ))}

https://github.com/billsix/bug

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.

Embeddable Common-Lisp does that

https://common-lisp.net/project/ecl/

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.

Why replace "struct" with "class"? These are completely different things. >.>

I don't see where you get that. There is a struct function.

That said, the only difference between a struct and a class is that struct member defaults to public, and class members default to private.

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

Hmm... would it be feasible to parse existing C code into an AST with an existing compiler front-end, and generate this kind of Lisp?

This could be very useful as a codegen alone.

I don't quite understand, is this a tool to generate C code, or you can use compiled result directly from CL?

So crazy it might just work.

I'd be surprised if something exactly like this but more mature and with a lot more questionable legacy design decisions doesn't already exist.

There's L++: https://bitbucket.org/ktg/l

And, for people who refuse to let go of curly braces, there's this shameless plug: https://github.com/eudoxia0/cmacro

There is the GSL by iMatix https://github.com/imatix/gsl (so closely associated with Pieter Hintjens of http://zeromq.org/)

Large part of low-level runtime of Gauche (Scheme dialect) is written in "C in S-expression", the same idea with this.

I found it so pleasant writing C in S-expr that I gradually rewriting my C code with it.

Historically the Scheme48 abstract machine was written in Pre-Scheme, a Scheme subset restricted enough to compile straightforwardly to C.

For me, using Pre-Scheme to write graphics kernels was great fun, and produced decently fast code :)

Historically? It still is! :)

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

There are some papers about both here: http://library.readscheme.org/page8.html

[1]: http://www.artinfo-musinfo.org/en/issues/vlisp/index.html

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

I really want this for D tbh. Looks clean though.

That is a lot of docs.

My first impression with the title was wrong, I thought about something related to Lisp and Y Combinator.

Yeah, this title really didn't match up with the project name or how it's pronounced.

Reply on news.ycombinator.com