gmlk wrote:I would like to see a common lisp based on llvm, with llvm as back-end. (more)

ECL is aiming at that right now (http://tream.dreamhosters.com). The goal is to replace the current bytecodes compiler and the lisp to C compiler by a common frontend that optionally produces either the same bytecodes, or C, or uses llvm as a backend. The only thing is that currently I am busy fixing some real problems with the lisp runtime, most of them related to the limitations of C interrupts and to thread safety. Sorry for trolling again

Ali Clark wrote:Please can we stay on topic?There are many implementations of Lisp in C, and there are implementations of Lisp in JVM and .NET . We can all have our cake and eat it.The discussion on this raises interesting facts, but I'm not sure it is going anywhere.

Sorry for trolling. I get too emotional sometimes In case I am permitted, my 2cts- Real in-browser support for CL, with access to the DOM and so on.- Serializable and persistent CLOS classes done right and transparently, with little overhead.- Sealed classes, where types are unboxed and slot access can be compiled efficiently.- A better definition of the multithreading package, with threads, locks, etc. Desperately needed by implementors - Network transparent pathnames that really allow you to access remote machines. ECL has the syntax, but we lack the real code.- Sandboxed CL processes, where execution is restricted to certain sections of the file system, limited resources, etc.- Not only multithreading, but also transparent execution on clusters, with process migration, etc.

I may have missed many of the libraries out there for these tasks, but I tend to be quite out of date, anyway O:-)

Juanjo, I'm happy you found LispForum. I'm using ECL right now for a project because of its small size. I'm happy that it exists and that you're SO responsive to all things that surround it. (Honestly, folks, if you haven't used ECL yet and seen how quickly Juanjo knocks off the bugs that are reported with it, you would be amazed.)

In case I am permitted, my 2cts- Real in-browser support for CL, with access to the DOM and so on.- Serializable and persistent CLOS classes done right and transparently, with little overhead.- Sealed classes, where types are unboxed and slot access can be compiled efficiently.- A better definition of the multithreading package, with threads, locks, etc. Desperately needed by implementors - Network transparent pathnames that really allow you to access remote machines. ECL has the syntax, but we lack the real code.- Sandboxed CL processes, where execution is restricted to certain sections of the file system, limited resources, etc.- Not only multithreading, but also transparent execution on clusters, with process migration, etc.

I may have missed many of the libraries out there for these tasks, but I tend to be quite out of date, anyway O:-)

Any thought to creating a "real" mod_lisp that would actually embed CL into Apache, similar to mod_perl, mod_python, mod_ruby, etc? I have thought for a while that ECL is perfect for that.

gmlk wrote:I would like to see a common lisp based on llvm, with llvm as back-end. (more)

ECL is aiming at that right now (http://tream.dreamhosters.com). The goal is to replace the current bytecodes compiler and the lisp to C compiler by a common frontend that optionally produces either the same bytecodes, or C, or uses llvm as a backend. The only thing is that currently I am busy fixing some real problems with the lisp runtime, most of them related to the limitations of C interrupts and to thread safety. Sorry for trolling again

TheGZeus wrote:Get ECL to work with CLX and StumpWM people will love you forever.

Oh, that would not be difficult. Portable CLX used to build in ECL. The only problem is that I lost my account in the project and got disconnected from it. There have been reports that the current library loads with some patches, but there are some compiler problems. I guess I should update the source tree with the most recent darcs tree.

findinglisp wrote:Juanjo, I'm happy you found LispForum. I'm using ECL right now for a project because of its small size. I'm happy that it exists and that you're SO responsive to all things that surround it. (Honestly, folks, if you haven't used ECL yet and seen how quickly Juanjo knocks off the bugs that are reported with it, you would be amazed.)

I am blushing right now You would not be amazed about the speed if you really knew how simple those bugs most of the time are, hehe.

findinglisp wrote:Any thought to creating a "real" mod_lisp that would actually embed CL into Apache, similar to mod_perl, mod_python, mod_ruby, etc? I have thought for a while that ECL is perfect for that.

Wow, I had a wonderful dinner discussion with some guys at the European Common Lisp meeting precisely about this. I must admit I did not work on that because of ignorance of the Apache API, but I think it would be really easy. Let's assume that Apache provides the module with a file descriptor to read from, another one to write to and the name of the file that contains the code, then I could write you three black-box functions: one for setting up ECL, another one for shutting it down, and another one for doing the work. It would probably look as follows (not checked), but perhaps with some additional lines for handling signals, and so on. Again, what scares me is all the Apache stuff