LispForum

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

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.

jjgarcia wrote: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:-)

jjgarcia wrote:

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.

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

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.

void mod_ecl_open() { cl_boot(0, 0); }

void mdo_ecl_close() { cl_shutdown(); }

int mod_ecl_run(int in, int out, const char *file)
{
   cl_object in_stream = ecl_make_stream_from_fd(Cnil, in, smm_input);
   cl_object out_stream = ecl_make_stream_from_fd(Cnil, out, smm_output);
   cl_object pathname = cl_parse_namestring(1, make_constant_base_string(file));

   cl_object code = c_string_to_object("(lambda (in out file) (let ((*standard-input* in) (*standard-output* out)) (load file :verbose nil :print nil)))");
   cl_object ok, fun =  si_safe_eval(3, code, Cnil, OBJNULL);
   if (fun == OBJNULL) return 0;
   ok = cl_funcall(4, fun, in_stream, out_stream, pathname);
   return ok == OBJNULL;
}

• Lisp 1 (like scheme, funcall & sharpquote are too verbose for functional programming)
• Functional (like clojure and erlang, i prefer functional stile to OO: OO feels like imperative++)
• No mutable state (again like clojure and erlang, also PLT scheme)
• Purely functional data structure are first class, no list centric, sequence types are abstact and lazy (like clojure)
• Vast functional library, with maps, filters, zippers, folds etc (like haskell)
• Concurrency via green threading and message passing (a la erlang, highly scalable, no mutable state so there's no need of locks)
• Files are modules, implict namespacing (like python and otter)
• Facilities for logic programming (oz & prolog), functional reactive programming.
• Standard libraries for network, db access, gui creation (clim), opengl & vector+raster graphics & sound (processing).
• Support for continuations (scheme)
• Both interpreted and compiled (like Common Lisp)
• Should be easy to create standalone executables, maybe not image based but with a default mechanism for persistance
Syntax details
• Small function names for most used functions, still readable (like arc and otter, NOT perl)
• def for definition, fn is lambda, (+ _ 4) is (lambda (x) (+ x 4))
• Hashtables are functions of their keys (like Clojure, arc), maybe list and arrays are functions of their index (like arc)
• Facilities for both Hygienic and Non-hygienic macros
• Reader macros should have a limited scope (maybe only the current module)