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 exception handling, the correct name is "Condition System". It is an approach more similar to Erlang, where you have common code for intercepting and managing certain classes of errors in an uniform way.
I didn't understood if the limitation about Coalton are regarding run-time errors, or compile-time errors. The condition system is only about management of run-time errors or run-time exceptional conditions.
It can be used also for implementing effects, when it is sufficient a manipulation of the stack. Otherwise Scheme continuations are more powerful.
