On 2/7/12 5:53 PM, Stefan Monnier wrote:
>>>> I've never understood what's wrong with including cl.el, nor why the
>>> The main issue is namespace.  If someone goes through the code to rename
>>> it all to "cl-*", then we won't need to avoid using it.
> 
>> I don't think the namespace is an issue. A _lot_ of people do, in
>> fact, (require 'cl), and packages continue to work for them. If there
>> were any serious conflicts, they'd already be fixed.
>> In other words, I don't think you can find an elisp package that only
>> works properly if cl isn't loaded.
> 
> That's not the issue.  The issue is that CL's namespace is really
> unclean and that's bad, regardless of whether other packages conflict.

While this allegation may be true, cl is so old and so generally
useful that it should be grandfathered in.

Also, cl.el _does_ take pains to use the "cl-" prefix for internal
symbols. It's the public interface that's unprefixed, and for the sake
of both convenience and backward compatibility, we shouldn't move the
entire CL library into its own namespace until we have some kind of
symbol namespace support.