What feature would you most like to see in Lisp?

[Ali Clark]

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.

[gmlk]

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

[jjgarcia]

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

[jjgarcia]

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

[findinglisp]

Sorry for trolling. I get too emotional sometimes

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.

[TheGZeus]

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

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

[jjgarcia]

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.

[jjgarcia]

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.

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

Code: Select all

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;
}

[MrSelfDefstruct]

Disclaimer: I'm currently studying various lisps, but I'm a beginner. And, as any other lisp newbie, I'm dreaming of the perfect lisp dialect
This is how I'd like it to be:

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

Can't think of anything else for now.

[danb]

A (setf if) macro would be nice, so you can say

Code: Select all

(let (goods bads)
  (dolist (x xs)
    (push x (if (goodp x) goods bads))))