What feature would you most like to see in Lisp?

[Ali Clark]

Title says it all.

Your answer can be anything you would like to see relating to any (or all) the Lisp dialects.

Try to be as specific as you can in your replies.

If you're extremely lucky, someone might actually know what you're looking for.

[August]

Hello everyone,

Just so you know where I'm coming from, my company develops computer graphics tools for the special effects and computer game industries. We use C++, but it's like driving around in first gear all day...there's got to be a better way I am presently working through SICP and Practical Common Lisp and, so far, am liking Lisp very much.

What we need:

Speed - Common Lisp looks pretty good here and, from what I understand, you can use type annotations and compiler settings to squeeze out speed where you really need it.

Up to date OpenGL bindings - I think that there are some out there but am not completely sure.

Ability to generate executables/dlls - I know that this may not be the Lisp way, but it is a practical consideration for us.

Multithreading - using multiple CPUs works very well for many computer graphics algorithms and this is something we really need. From what I have seen, this seems to be hit or miss with Common Lisp implementations. Lispworks only allows a single thread to run Lisp code at a time but lets foreign functions run in parallel with the Lisp thread which might be enough of a workaround for us. It sure would be nice to have parallel Lisp execution though

Cross platform GUI toolkit (Windows/OSX) - we use Qt now, which has worked well for us.

Anyway, that's my short list. Parallel execution on multiple CPUs is what I'm most interested in.

August Swanson

[Ali Clark]

Hi August,

For the OpenGL, the library at http://common-lisp.net/project/cl-opengl/ might help. Not sure how up to date it is, but it was committed to a week ago, so hopefully it is.

For executable compilation, check this recent topic on compiling to an "exe". There are a few snippets for each implementation and a couple of portable versions.
http://groups.google.com/group/comp.lan ... e89d1518e7

I'm not sure about multithreading or GUI though. If you don't find answers for those soon you could ask on comp.lang.lisp or IRC #lisp, but hopefully there'll be an archived conversation on each somewhere.

[schoppenhauer]

Since I dont use Scheme (or anything else) often, I can only talk about Common Lisp.

Some feature I am really missing for programming is some kind of automatical recompiling if you change some constant, i.e., if i write (defconstant bla 2) and again (defconstant bla 3) while developing, it would be nice if all functions who depend on that constant would be recompiled - it can be annoying to do this manually, just because some constant changes.

Defining Classes after having been used in Method-Declarations would be a nice thing too (as this will give you more freedom in code-arrangement).

Another thing would be an addition to have something like "java-interfaces" (abstract classes), i.e. to define a few Methods that must be defined for any sub-class, otherwise you will get an error (or at least a warning) if you try to create an instance of that sub-class - this helps programming, it doesnt add anything really useful to Common Lisp.

Real, native Continuations would be a nice thing, too.

[August]

For the OpenGL, the library at http://common-lisp.net/project/cl-opengl/ might help. Not sure how up to date it is, but it was committed to a week ago, so hopefully it is.

For executable compilation, check this recent topic on compiling to an "exe". There are a few snippets for each implementation and a couple of portable versions.
http://groups.google.com/group/comp.lan ... e89d1518e7

I'm not sure about multithreading or GUI though. If you don't find answers for those soon you could ask on comp.lang.lisp or IRC #lisp, but hopefully there'll be an archived conversation on each somewhere.

Thanks much for the info. I have actually been watching the topic on creating an "exe" with much interest. Does anybody know if SBCL has multiprocessor support...Lisp running on multiple CPUs simultaneously? I downloaded the Windows install today and played around with it but that is a unithread build.

[Paul Donnelly]

Does anybody know if SBCL has multiprocessor support...Lisp running on multiple CPUs simultaneously? I downloaded the Windows install today and played around with it but that is a unithread build.

Looks like a qualified yes.
http://www.sbcl.org/manual/Threading.html

[Ali Clark]

Does anybody know if SBCL has multiprocessor support...Lisp running on multiple CPUs simultaneously? I downloaded the Windows install today and played around with it but that is a unithread build.

Looks like a qualified yes.
http://www.sbcl.org/manual/Threading.html

Although its possible that the threading doesn't work on Windows yet, since Windows isn't mentioned on that page and the port is behind the Linux version (http://www.sbcl.org/platform-table.html).

For the GUI, McCLIM (http://common-lisp.net/project/mcclim/) should work on Windows and appears be maintained and used in a few apps. There was a Qt binding library, but it appears to have stopped development at v0.2 some time ago.

[Kompottkin]

Apart from a well-established, high-quality, and cross-platform GUI library, which, apart from Java with its JFC/Swing framework, doesn't really exist for any language, what I'd most like to see is something like this:

Code: Select all

#include <stdio.h>

(defun mulk ()
  (c::printf "Hello %s!" "world"))

And for ridiculous bonus credits:

Code: Select all

#include <iostream>

(defun mulk2 ()
  (c++::<< c++-std::cout "Hello " "world" "!" c++-std::endl))


A pipe dream, I'm sure.

[Ali Clark]

Certainly not a pipe-dream. You need a C header parser like cparse (http://common-lisp.net/project/cparse/), and the FFI ofcourse. From there you should be able to do something like (printf ...).

The #include ... statement can be implemented through a reader macro. The < ... > path delimiters could also be implemented. However its probably better just to use write a (c-include "stdio" :global t) function or similar.

Inside the c-include function, you would check to see if the FFI bindings for that header already exist, and if not you would search for the header file, cparse it, save the bindings somewhere, and then load them.

The second example seems a lot more difficult because it uses weird operator overloading stuff, but you could try rolling your own with fprintf I guess.

McCLIM is probably the closest thing we have to that GUI

[dmitry_vk]

I'd like to have standardized support for threads. Having threads is a must for many things: for web-apps, for GUI apps (actually, for almost everything except command-line apps). There is threading support in many implementations, but API and semantics differ. Having a supported threading API would be a great improvement.