drmeister

I think for naming purposes we should go with "cclasp" as the name.

Thanks - yes it's fun and very powerful. An integral part of Clasp is "clasp-analyzer" - a static analyzer that uses the ASTMatcher library to analyze all of the Clasp C++ source code (>170 source files). It builds an interface to the Memory Pool System garbage collector (coming soon) and builds a fast replacement for dynamic_cast. We are planning to use it to write a "super-swig" that could automatically build foreign function interfaces for C++ code.

There are several. In Clasp there is https://github.com/drmeister/clasp/blob/master/src/asttoolin... - that exposes the entire Clang AST class hierarchy. Then there is https://github.com/drmeister/demo-clasp-cxx - it exposes a small "Hello World" example. Then there is the SFML library that is being exposed by flash- one of the regulars in the #clasp IRC channel: https://github.com/clasp-developers/clasp-sfml

Yes - I have a plan to clean it up. Clasp exposes the clang source to source translation library. Now that it's fast I'm going to automatically refactor the whole thing in one go.

Announcing Clasp 0.4 – a new release that incorporates a brand new compiler – capable of generating 200x faster code than previously, many bug fixes, a more complete Common Lisp implementation, and improved C++ interoperation.

Thank you, you summed it up better than I could.

In short Common Lisp has two namespaces, one for functions and macros and a second for variable names - Scheme has one namespace. So you have fewer conflicts in naming in Common Lisp. In Scheme there is a lot of concern about hygienic macros that don't mess up the namespace. For more on that here is an inflammatory but well thought out exposition. http://www.xach.com/naggum/articles/3236789642671151@naggum.... The book Let Over Lambda lays it out really well as well.

I've implemented a Common Lisp that interoperates with C++ and uses LLVM as the backend because I was motivated by the same shortcomings in traditional software development languages and tools (https://github.com/drmeister/clasp). I choose Common Lisp rather than Scheme because the killer feature of Lisp is Macros and they are easier to use in Common Lisp than they are in Scheme. Also, Slime (Emacs interface to Common Lisp) is one of the most powerful software development environments available IMHO.

Christian Schafmeister here with a shoutout to the Ravenbrook people who are awesome and very helpful. They have excellent documentation: https://www.ravenbrook.com/project/mps. I don't own stock or anything but now that I'm using MPS I'd like more people to know about it. If you are interested in developing a more generalized version of the static analyzer that I wrote to automate GC for C/C++/Objective-C - get in touch with me.

Christian Schafmeister here - thanks! You make some very good points that I can address: (1) Things made with "Molecular Lego" still move, but they keep their shape just enough to organize atoms/groups to do things like speed up reactions and bind other molecules. We've explored dynamics in several of our papers. They aren't too constrained - they are constrained "just enough"; and we can build in flexibility and hinges where ever we want. (2) We don't know how to make mechanical molecular machines with them yet; we need to start making a lot of them and explore their properties to figure that out. The first folks who smelted iron didn't know how to build motors with it - it took a lot of people playing around with iron for a long time to figure that out. I think we can get there in less time but it will take work. (3) Re: toxicity/pollution - this is the first non-natural molecular technology that contains the solution to any problems that it generates. We need to learn how to make catalysts well and then we can build catalysts that break these molecules down. Conceivably, we could build materials that contain the catalysts that break them down and are activated by an external signal. Or we make materials out of bigger bricks (built from Molecular Lego) and we fish them out of the environment, tear them apart from each other, check them for defects and build new materials with the good ones and recycle the broken ones. We can also build catalysts that break down every other indestructable material that we've been dumping into the environment for 100 years. Regarding toxicity, these molecules are made out of carbon, nitrogen, oxygen and hydrogen - the same atoms you are made out of. They are inherently non-toxic (there are qualifiers on this).

Hi, I'm Christian Schafmeister. Thank you so much for the nice comments! I just want to point out that this work was all done with your tax dollars. This work was made possible by support from the National Institute of Health (NIGMS), the National Science Foundation (NSF) and the Defense Threat Reduction Agency (DOD:DTRA).

Because it's the only language worth talking about :-)

I developed it on OS X so that's a good choice. The README on github lists the linux distributions that it's been compiled on.

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.

Thanks - yes the analyzer tracks roots through about 300 C++ classes. It also finds global variables and builds C++ code to interface with the MPS library. I exposed the Clang libraries to search the AST and describe the AST in Common Lisp and then wrote the static analyzer in Lisp. I shudder at the thought of doing this all in C++ and I write a lot of complicated stuff like Common Lisp implementations in C++ :-). Common Lisp is the language of trees and pattern recognition. Common Lisp is the perfect tool for this job.

Yes, the Memory Pool System by Ravenbrook (https://www.ravenbrook.com/project/mps/) is a proper, moving garbage collector. It uses precise GC on the heap and conservative GC on the stack, as does the garbage collector in Steel Bank Common Lisp on x86 chips. I need it because I need my code to run on 100,000 CPU supercomputers with a controlled memory footprint to develop organic nano machines (seriously).

Agreed, but it's more of a "tree-shaking problem" than anything else. Clasp is written in C++ and Common Lisp. Clasp compiles Common Lisp to LLVM-IR and Clang compiles C++ to LLVM-IR. So theoretically you could compile everything to LLVM-IR and feed that to emscripten. Granted, it's going to be a _huge_ LLVM-IR file. Then you shake out the functions and globals that aren't needed. If the compiler isn't needed then it will shake out (or not be compiled in in the first place). The question for me is "what problem does it solve". I assume there are problems that I'm not aware of that it would solve, otherwise why would someone develop emscripten? Common Lisp is a fantastic language that is really underutilized, it's fun and so expressive. I fell in love with Common Lisp three years ago so deeply that I wrote a new Common Lisp to solve my scientific programming challenges while still being able to make use of powerful C++ libraries. I think everyone should use it everywhere - it's awesome.

I disagree. Clasp could do this because it compiles Common Lisp to LLVM-IR bitcode files (using COMPILE-FILE) as well as directly to native code using LLVM's MCJIT engine (using COMPILE). emscripten (https://github.com/kripken/emscripten) says that it compiles LLVM-IR to JavaScript. I haven't used emscripten, but I believe everything I read on the internet :-) and thus Common Lisp --[Clasp]--> LLVM-IR bitcode files --[emscripten]--> run within browsers.

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.

Yes, LLVM is awesome. Clasp uses the inlining LLVM provides to inline C++ code within Common Lisp code by generating LLVM-IR bitcode files from C++ source and linking them with Clasp generated bitcode files and then running them through LLVM module and function optimization passes. I'm really excited about combining the CL specific optimizations with the ones that LLVM provides - stay tuned.

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.

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