>Programmers can expose C++ classes as well as functions and class methods with a single line of code that provides the Clasp name and a pointer to the function/method.
It would be really shiny to have a cross-platform GUI library in CL without grief. I've prodded that space repeatedly in the last 6 years and simply have not come away happy about any of it except LispWork's library.
A faster Clasp compiler is coming soon – the current Clasp compiler generates slow native code that is about 100x slower than highly tuned Common Lisp compilers like Steel Bank Common Lisp.
No mention of the expected speedup, but 100x is a huge performance problem.
The reason is that Clasp doesn't do Lisp language level optimizations like escape analysis yet. All bindings are stored on the heap and the stack/registers are underutilized. LLVM is a great library for implementing C and C++ but more work needs to be done to support Lisp features like closures and first-class functions. We are working on that now. The goal was first to "make it correct" and now we will "make it fast". Once we have a faster compiler (give us a couple of months) I don't see why it couldn't approach the speed of SBCL (a tall order).
I'm not too worried, since a) that makes it about as fast as cpython and b) there is a lot of low-hanging fruit. There is work being done on integrating the Cleavir compiler which does a number of tricks. In particular escape analysis and lambda lifting should both help a lot on certain types of code.
Essentially, LLVM does tons of low-level optimizations but Clasp does few high-level, CL-specific ones. SBCL, on the other hand, mostly does CL-level optimizations and few low-level ones.
Almost certainly can't. The closest you can get is using clicc or ECL or something similar to generate C code, and then compile that with emscripten.
This invokes llvm at runtime, and AFAIK emscripten isn't ported to emscripten.
FWIW, I've tried other lisps under emscripten:
Most lisps generate machine code, store them in RAM, and then execute that RAM. This is not possible under emscripten.
Clisp is a good candidate, since it's byte-code interpreted rather than generating machine code, but clisp makes so many assumptions about how the machine works (in particular it strongly wants a C style stack and does manual stack-pointer manipulation). I actually got fairly far into the bootstrap process under emscripten, but the minimal lisp interpreter it compiles generated bizarre errors.
I don't see why we couldn't do this. emscripten (https://github.com/kripken/emscripten) says it takes LLVM-IR to JavaScript. The Clasp (Common Lisp) function COMPILE-FILE compiles to LLVM-IR bitcode files. If you have some time and you would like to do this - hit me up with an email - I'd love to make this happen.
Is this project something that you're doing to support your own research goals in computational chemistry? If so, can you share how this project fits into the bigger picture?
SBCL doesn't generate LLVM code. My primary goal was Common Lisp with C++ interoperation. It seemed easier at the time to start from the ECL Common Lisp code base and write a new C++ core and a Common Lisp interpreter that always interoperated with C++. As I wrote the compiler and expanded the system I maintained C++ interoperation all the time. There were a hundred problems that I had to discover and solve along the way to maintain a Common Lisp that interoperated with C++. You can get some level of interoperation between ECL and C++ up in a weekend but it won't work with C++ exceptions and RAII and there are dozens of other problems. In retrospect I don't think I would have gotten here starting from ECL because I never really understood the ECL code.
I would point out that MOCL https://wukix.com/mocl pretty much provides this functionality only with full Common Lisp compatibility. It compiles the CL to C and adds methods to expose your functions to Obj-C / C code (if you want). Works just fine. Builds with Xcode, which as I understand, does everything on/via LLVM.
mocl is different from many other implementations: it is a batch compiler for whole programs to C. The generated code does contain a limited evaluator and no compiler. Some dynamic features are gone...
> Clasp exposes the Clang AST library and the Clang ASTMatcher library. This allows programmers to write tools in Common Lisp that automatically analyze and refactor C++ programs. Clasp can be used to automatically clean-up and refactor large C++ codebases!
Yes, I'll post more on this and provide example code in the coming weeks on the blog. It's really exciting and it's something that Clasp can do right now even though the Clasp compiler isn't a highly optimizing one yet. Google uses automated Clang refactoring to clean up the googleplex (100 megaLOC). Clasp puts those capabilities into everyones hands now.
Package: clasp
Version: 3.1.0-1
Description-en: conflict-driven nogood learning answer set solver
clasp is an answer set solver for (extended) normal logic
programs.
It was also already taken by a device for fastening things. And my name was already taken by at least three people before me. Somehow we all get along.
[+] [-] eudox|11 years ago|reply
Hellooooo Qt without Smoke bindings.
[+] [-] pnathan|11 years ago|reply
[+] [-] phkahler|11 years ago|reply
A faster Clasp compiler is coming soon – the current Clasp compiler generates slow native code that is about 100x slower than highly tuned Common Lisp compilers like Steel Bank Common Lisp.
No mention of the expected speedup, but 100x is a huge performance problem.
[+] [-] drmeister|11 years ago|reply
[+] [-] krig|11 years ago|reply
[+] [-] aidenn0|11 years ago|reply
[+] [-] eudox|11 years ago|reply
Essentially, LLVM does tons of low-level optimizations but Clasp does few high-level, CL-specific ones. SBCL, on the other hand, mostly does CL-level optimizations and few low-level ones.
[+] [-] ephemeralgomi|11 years ago|reply
[+] [-] wtbob|11 years ago|reply
[+] [-] aidenn0|11 years ago|reply
This invokes llvm at runtime, and AFAIK emscripten isn't ported to emscripten.
FWIW, I've tried other lisps under emscripten:
Most lisps generate machine code, store them in RAM, and then execute that RAM. This is not possible under emscripten.
Clisp is a good candidate, since it's byte-code interpreted rather than generating machine code, but clisp makes so many assumptions about how the machine works (in particular it strongly wants a C style stack and does manual stack-pointer manipulation). I actually got fairly far into the bootstrap process under emscripten, but the minimal lisp interpreter it compiles generated bizarre errors.
[+] [-] S4M|11 years ago|reply
You have Parenscript for that: http://common-lisp.net/project/parenscript/
(I haven't used it yer though.)
[+] [-] drmeister|11 years ago|reply
[+] [-] mateuszf|11 years ago|reply
[+] [-] arvid|11 years ago|reply
[+] [-] mcmancini|11 years ago|reply
Is this project something that you're doing to support your own research goals in computational chemistry? If so, can you share how this project fits into the bigger picture?
[+] [-] yvdriess|11 years ago|reply
I wonder why start from scratch for an LLVM backend, can't SBCL be used to generate LLVM code?
[+] [-] drmeister|11 years ago|reply
[+] [-] aidenn0|11 years ago|reply
[+] [-] ioddly|11 years ago|reply
[+] [-] masukomi|11 years ago|reply
[+] [-] lispm|11 years ago|reply
[+] [-] aidenn0|11 years ago|reply
[+] [-] latiera|11 years ago|reply
[+] [-] JabavuAdams|11 years ago|reply
Niiice. I want to program C++, but not in C++.
[+] [-] drmeister|11 years ago|reply
[+] [-] tempodox|11 years ago|reply
[+] [-] fithisux|11 years ago|reply
[+] [-] tunnuz|11 years ago|reply
[+] [-] edwintorok|11 years ago|reply
[+] [-] lispm|11 years ago|reply
http://www.cs.cmu.edu/afs/cs/Web/Groups/AI/lang/lisp/code/ma...
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.138.... http://dl.acm.org/citation.cfm?id=896952
Later another CLASP: Common LISP as simulation program (CLASP)
https://github.com/openlisp/clasp
[+] [-] chc|11 years ago|reply
[+] [-] andrewchambers|11 years ago|reply
[+] [-] 616c|11 years ago|reply