I've been looking around the web trying to check out the state of GUI toolkits available for CL. I've not yet settled on any particular implementation yet (clisp/sbcl), still learning the language, but for future reference I was just wondering what the state of particular CL packages providing GUI toolkits is?

Through ABLE, I've seen the TK interface, which is too dated even for my standards. Preferably, I'd like to use GTK as I've used it with C, but the projects seem a bit dead. Am I right, or do they not need updating (ie the auto-api-generation projects)?

Also, some of the GTK CL APIs (or whatever they're called in CL) seem to have preference for SBCL (as opposed to CLISP) which narrows my choice if I want to use CLISP or forces me to use SBCL. Is SBCL generally better supported by packages than CLISP, and is this a good enough reason to use SBCL or CLISP?

(SBCL/CLISP: anything to do with licensing issues? ie BSD/MIT vs GPL, i'm not that up on it, but I generally use the GPL for code I release as I want to give users freedom without users being able to take that freedom from others, I guess, eh.)

jwm-art wrote:Is SBCL generally better supported by packages than CLISP, and is this a good enough reason to use SBCL or CLISP?

SBCL and CLISP have quite different implementation objectives. CLISP is highly portable and has small image size, but slow, and SBCL has a native compiler, which means it is fast but much harder to port between systems and architectures. Since most open-source Lisp packages authors use Linux, they use primarily SBCL, and hence their packages are usually supported there better.

But, Common Lisp is a standardized language, which means that portable code should work on all conforming implementations, and extensions can usually be papered over with compatibility libraries. This means that this shouldn't really be a deciding implementation factor. I think that SBCL is better for most applications, especially if you are not going to try to deploy your programs on exotic systems.

jwm-art wrote:Through ABLE, I've seen the TK interface, which is too dated even for my standards. Preferably, I'd like to use GTK as I've used it with C, but the projects seem a bit dead. Am I right, or do they not need updating (ie the auto-api-generation projects)?

If you are using Linux, there is also two very recent bindings for Qt, cl-smoke and commonqt. IMO cl-smoke has a much better (and more Lispy) approach, not to mention that it also provides bindings for the entire kde API, but, to use it, you will have to set mudballs up (which is easy). For both of them you need to install KDE's smoke libraries, which is easy on Linux (just a matter of finding the right package), but it is not that easy on Windows.

About implementations, I believe you don't need to be that concerned right now. If you start using some internal functions of some implementation (e.g. threads, sockets, MOP, ...), it will be very easy to transform your code to use portability libraries instead of internal functions. Porting CL code from implementations is an easy task (ok, not always, but most times). Therefore you should use the implementation you like more. You can even install multiple implementations and eventually test some code in all of them.

jwm-art wrote:Is SBCL generally better supported by packages than CLISP, and is this a good enough reason to use SBCL or CLISP?

SBCL and CLISP have quite different implementation objectives. CLISP is highly portable and has small image size, but slow, and SBCL has a native compiler, which means it is fast but much harder to port between systems and architectures. Since most open-source Lisp packages authors use Linux, they use primarily SBCL, and hence their packages are usually supported there better.

Just for the OP's reference, the usage is pretty clearly in SBCL's favor, with CLISP being #2. See...viewtopic.php?f=2&t=140

Ramarren wrote:But, Common Lisp is a standardized language, which means that portable code should work on all conforming implementations, and extensions can usually be papered over with compatibility libraries. This means that this shouldn't really be a deciding implementation factor. I think that SBCL is better for most applications, especially if you are not going to try to deploy your programs on exotic systems.

Yes, but also to be clear, most GUI toolkits require FFI bindings and FFIs (foreign function interfaces, for the those new to CL) are not a standard part of the language and are thus not typically portable. While there are portability layers (CFFI, UFFI, etc.) that help to smooth over some of the rough spots and provide some measure of FFI portability, they are not perfect and you'll find the most implementation-specific code written for libraries which interface to the outside world and thus cannot rely on standard CL to get the job done.

All that said, Ramarren is quite correct than generally SBCL is the most well-supported of all the implementations, particular on Linux. If you're working on Mac, you might have better luck with Clozure CL (CCL), which has a long Mac history. On Windows, it's a complete crap-shoot, I think. I personally use CLISP on Windows and generally don't do anything that requires more than basic standard CL functionality when I do.

I'd also add to Ramarren's comment about CLISP being "slow." Yes, while slower than SBCL because it's a more-portable byte-compiled implementation, when we say "slow" here, we're still talking the rough speed equivalent of other scripting languages such as Perl, Python, Ruby, etc. And yes, I know those all have a wide speed range as well. The point is, we aren't talking about something pitifully slow or unusable. But as Ramarren points out, SBCL is a native compiler which is faster but more difficult to port.

I'm using Cells-GTK and CLG (two GTK bindings) with cl-opengl and cairo bindings (from CLG) on SBCL/Linux for real-time data visualization. I have no need to port the application to Windows, but if I should, I'd try ClozureCL + either of these GTK bindings, as GTK is avaivable for Windows, too.

Last edited by hrapof on Wed May 27, 2009 9:38 pm, edited 1 time in total.