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

[Drew Adams]

> > 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
> 
> These are exactly our goals.  We've been doing this for years: that's
> how stuff like 'when', 'unless', 'push', 'pop', and others got into
> the core.

Great.  But I think this happened without any
particular, explicit program/goal to
discover/discuss/understand which things are
the candidate "useful cl ideas" to consider.

Nothing wrong with that lack of explicit goal,
per se.  But it speaks a bit to the situation
or problem you raise of some people being too
eager to use/include whatever they personally
want ("unconstrained liberty of using all or most"):

> The problem (at least my problem) is that some of the people in this
> discussion don't agree with this cautious and slow approach.  They
> want the unconstrained liberty of using all or most of cl-lib and its
> extra libraries everywhere, and they consider any request to avoid
> using these facilities an unacceptable pressure.  They basically want
> cl-lib, cl-extra, etc. preloaded and always available for use,
> regardless of the aspects you mention above and without any
> restrictions.

I think that Michael's follow-on point/goal,
which you didn't comment on, would help with
that problem you raised, because it would be
less likely to always remain a question of
all-or-nothing change or personal preference: 

  And: one main problem we have is that cl-lib
  is more or less a huge monolithic block (as
  a `require'able library).  Why not split it up?
 
> We use keyword arguments when there are many of them, or when a few of
> them are obscure and rarely used.  From where I stand, the dispute is
> not about banishing then -- that will not happen -- the dispute is
> about how _much_ to use them.

I suggested we start with considering more use
of :key and :test, IOW, look for places where
those might simplify things.  (And no, that
doesn't mean we need to add them here & there
willy nilly, e.g. get rid of `memq'.)