What features of #CommonLisp can't be found in a larger #scheme distribution? I feel like I'm always hearing that scheme isn't full-featured enough for most #lisp hackers, but it's unclear what the average scheme is usually missing. On the other hand, I can think of quite a few features common in among schemes that you won't find in CommonLisp.

@rml CLOS and MOP are better respect many Scheme OOP libraries.

Generic functions are used also in contexts different from OOP.

CL macros are easier to write.

The error and exception handling of CL is very powerful and useful.

But the real answers for me are these:

1) CL live coding (i.e. interactive REPL) is very fun and addictive

2) there are many CL compilers with different characteristics at run-time accepting the same CL code, and that you are sure that you can use in production. For example with ECL you can produce C-friendly libraries.

3) a minor detail, but I like the fact that "nil" stays for false, and every other value for "true". The code become shorter.

@mzan
// CLOS and MOP are better in every respect to many Scheme OOP libraries

It seems to me this can be said at the level of implementation, but there isn't much "out of reach" (in terms of having to alter the scheme implementation in order to implement certain CLOS features). afaik CLOS is primarily better than for example GOOPs because its faster and very refined. But I realize I'm unfamiliar with some of the deeper functionality that CLOS might offer that would be difficult to achieve with a scheme implementation, and interested to understand what that might be.

// Generic functions are used also in contexts different from OOP

We have define-generic which works (afaik) just like CL's defgeneric. I'm interested in understanding the limitations of scheme's various CLOS implementations though, because its a topic I have a growing interest in

// CL macros are easier to write.

This is definitely true, but most major scheme implementations include defmacro. Still, I prefer hygienic macros.

// The error and exception handling of CL is very powerful and useful.

But as powerful as scheme? I know that Robert Smith said that the lack of syntax-objects are a major obstacle in providing the DX he would like to for Coalton, because they provide source location information and other very valuable introspective facilities for providing really nice errors. And that's something "out of reach" for CL

// But the real answers for me are these:

//1) CL live coding (i.e. interactive REPL) is very fun and addictive

I agree SLIME is very fun, but its not my style (I find it jarring). But if you want SLIME style debugging, MIT Scheme provides a similar experience. My ideal is the Chez "expeditor" debugger; it provides incredibly powerful reflective editing that i imagine are out of common lisp's reach due to lack of first class continuation support.

// 2) there are many CL compilers with different characteristics at run-time accepting the same CL code, and that you are sure that you can use in production. For example with ECL you can produce C-friendly libraries.

This is CL's major draw IMO

// 3) a minor detail, but I like the fact that "nil" stays for false, and every other value for "true". The code become shorter.

Nil is true for false and false for true? Sorry having trouble parsing this, perhaps because its been a couple years since I looked at CL. In scheme we have #f and '()

@rml regarding `nil`: in CL it stays for the empty list and for the false value. There is no false value in CL. There is no true value in CL. Everything that is not `nil` is considered a true value.

To be sincere, it is an hack respect the elegance of Haskell algebraic approach. But, it is a convention that fits very well in the CL code and its usual semantic. For example `(or (car some-list) 0)` return the first non-nil value. It seems an hack like 0 and 1 that in C is false and true, but instead it allows to write very composable code. So it is a powerful and elegant hack.

On all other points, or I agree with you, or I trust you, because you seems more knowledgeable than me.