Comparing Common Lisp with Gambit w.r.t their library access and object systems

Question

I'm pretty intrigued by Gambit Scheme, in particular by its wide range of supported platforms, and its ability to put C code right in your Scheme source when needed. That said, it is a Scheme, which has fewer "batteries included" as compared to Common Lisp. Some people like coding lots of things from scratch, (a.k.a. vigorous yak-shaving) but not me!

This brings me to my two questions, geared to people who have used both Gambit and some flavor of Common Lisp:

1) Which effectively has better access to libraries? Scheme has fewer libraries than Common Lisp. However, Gambit Scheme has smoother access to C/C++ code & libraries, which far outnumber Common Lisp's libraries. In your opinion, does the smoothness of Gambit's FFI outweigh its lack of native libraries?

2) How do Scheme's object systems (e.g. TinyCLOS, Meroon) compare to Common Lisp's CLOS? If you found them lacking, what feature(s) did you miss most? Finally, how important is an object system in Lisp/Scheme in the first place? I have heard of entire lisp-based companies (e.g. ITA Software) forgoing CLOS altogether. Are objects really that optional in Lisp/Scheme? I do fear that if Gambit has no good object system, I may miss them (my programming background is purely object-oriented).

Thanks for helping an aspiring convert from C++/Python,

-- Matt

PS: Someone with more than 1500 rep, could you please create a "gambit" tag? :) Thanks Jonas!

Bukharin

Answer 1

1) I haven't used Gambit Scheme, so I cannot really tell how smooth the C/C++ integration is. But all Common Lisps I have used have fully functional C FFI:s. So the availability of C libraries is the same. It takes some work to integrate, but I assume this is the case with Gambit Scheme as well. After all, Lisp and C are different languages..? But maybe you have a different experience, I would like to learn more in that case.

You may be interested in Quicklisp, a really good new Common Lisp project - it makes it very easy to install a lot of quality libraries.

2) C++ and Python are designed to use OOP and classes as the typical means of encapsulating and structuring data. CLOS does not have this ambition at all. Instead, it provides generic functions that can be specialized for certain types of arguments - not necessarily classes. Essentially this enables OOP, but in Common Lisp, OOP is a convenient feature rather than something fundamental for getting things done.

I think CLOS is a lot more well-designed and flexible than the C++ object model - TinyCLOS should be no different in that aspect.

Hackberry

The problem with merely having an FFI is that it forces you to wrap every function that you touch from Lisp. Even with the help of SWIG, this can quickly become a chore. Gambit has the advantage of allowing you to insert a block of C (and C++!) code right into your Scheme source. In other words, you only have to write interface code for whatever data you need to pass into and out of that block, not for every function in that block. This is great because you often need to use a bunch of C/C++ functions together to produce the result you're interested in, and only care about wrapping the result. – Bukharin

@SuperElectric: But you can always put that block of C (or C++) code into a C function, and then access this function through FFI. – Serif

@MiklósHomolya True, but it's a question of convenience. From my experience with Lush, I can say that being able to just put some C code in the middle of a lisp fucntion body and have it be able to access any lisp variable in scope is a big productivity win. – Bukharin

Late to the party, but for posterity's sake: ECL, an implementation of Common Lisp, allows you to do the same thing. – Penley

Answer 2

Sure Scheme as a whole has fewer libraries in the defined standard, but any given Scheme implementation usually builds on that standard to include more "batteries included" type of functions.

Gambit, for example, uses the Snow package system which will give you access to several support libraries.

Other Schemes fare even better, having access to more (or better) support libraries. Both Racket (with PlaneT) and Chicken (with eggs) immediately come to mind.

That said, the Common Lisp is quite rich also and a large number of interesting and useful libraries are a simple asdf-install away.

As for Scheme object systems, I personally tend to favor Chicken Scheme and have taken to favoring coops. That said, there's absolutely nothing wrong with TinyCLOS. Either would serve well and don't really find anything to be lacking. Though that last statement might have more to do with the fact that I don't tend to rely on a lot of object oriented-isms when writing Scheme. Both systems in my experience tend to surface when I want to write "protocols" and then have a way of specializing on the protocol, if that makes sense.

Locarno

"Both systems in my experience tend to surface when I want to write "protocols" and then have a way of specializing on the protocol, if that makes sense." ... ermmm not really. What systems are you referring to, and could you define 'protocol'? – Bukharin

the systems being the Object Oriented systems I'd mentioned. Protocol is a generic method, and TinyCLOS (or coops) objects then provide type parameter specializations to the method, so that a similar interface can be utilized for multiple types. Best analogy I can think of is a C++ template method, where you can specialize (provide custom behavior) base on the type of input. – Locarno

There's a chapter in the book Practical Common Lisp that does a better job than I of explaining. You can read it here: gigamonkeys.com/book/… – Locarno