RE: [External] : Re: What's missing in ELisp that makes people want to use cl-lib?

[Drew Adams]

There's much (maybe most) of what you say here,
Michael, that I agree with - in particular,
that the devil is in the details and blanket
opinions aren't very helpful.

I'll reply mainly to this, saying that I think
it makes a lot of sense:

> My goal would be like this:
> 
>  - keep cl-lib available to it's current extent for end users
>  - try to get unnecessary cl-lib uses out of the code base
>  - make useful cl ideas available in the core language
> 
> And: one main problem we have is that cl-lib is more
> or less a huge monolithic block (as a `require'able library).

Indeed.  That's what comes, I think, from its
creation as an attempt at emulating most of
what is, in effect, a huge, other, language:
Common Lisp.

(I'm glad that we _have_ such a wide-ranging
emulation, but it shouldn't be so monolithic
to use, understand, and debug.)

> Why not split it up?

100% agreement.  Just what split to end up with
might be more difficult and more controversial
to decide.  But worth discussion, at least.

And whatever the split in terms of supported
functions/features, maybe split off the defs of
macros needed for those split-off functions and
features.

We used to be able to just load `cl-macs.el' at
compile time, to get support for some `cl.el'
features without loading the latter.  Now,
`cl-macs' requires `cl-lib anyway.  (But see
previous paragraph - it might be good to split
up the macro defs as well, instead of having
all the macros for all of our emulation of CL
in one file.)

> I don't see why it is necessary that when I
> want to use a small useful cl thing that
> cl-loop must be made available.  Such things
> could go to its own library, name it cl-obscure
>  when you want.

Yes.  But put `cl-loop' in its own file - it's
a monster (essentially another language, on its
own).

And it's not just `cl-loop' - split `cl-lib'
into multiple files, according to some useful
criteria (maybe including arcaneness, lack of
overlap with other Elisp constructs, etc.).
(I can imagine there would be varying opinions
about the splitting vs lumping. ;-))

> cl-lib is big.  I would like us to try to
> factor it when the size is a problem (is it
> a practical, objective, or more or less mainly
> only a psychological problem btw?

I think it's probably a problem in multiple ways.

It's a _practical_ problem both (1) for users
(who don't want to load everything just to get
something) and (2) for Elisp maintenance and
evolution (a monolithic monster means discussion
and decision are more difficult; the scope
quickly becomes/grows too wide for each question
that might come up).