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

[Michael Heerdegen <michael_heerdegen@web.de>]

Po Lu <luangruo@yahoo.com> writes:

> I don't appreciate "function combination," whatever that is.
>
> In a language such as C, the function of a single block is clear.  Each
> block commences with a list of one declarator for each variable.
> [...]
> If it is to these that you apply the moniker "multi-line raw loop choo
> choo trains," then they are precisely what should be written more, not
> less.

Side note: I'm not a "fan" of cl-lib, and I hate cl-loop.  I hate it
when I need to understand code that uses it.

But this discussion has some aspects that I don't like - forcing other
programmers to share the own likes and ways of programming, "without
discussing each decision" although these decision have a very broad
reach, are backward incompatible and throw away the long-year work of
very committed and not unintelligent people.  Be aware that some things
in cl-lib are very well written and you'll need a very long time to to
develop a replacement of even approximate quality.  This discussion has
too much from "Personally I don't like this, let's just throw it all
away and start from scratch" that I only know from maybe a bit naive
people in emacs-help.

I understand most of your points of criticism.  A lot of parts of cl-lib
are not very useful for core Emacs, are harmful when used, should be
avoided as much as possible.  OTOH, there also are the useful things,
`cl-labels' (it had been mentioned as a main example) is definitely
among them for me.  Simple, well-defined and used to implement other
things...  I can't believe that it is an expectation that somebody's
personal preferences and likes should be the only guide of how to
proceed.

cl-lib started as emulation package for Common Lisp.  It was a huge work
to get it where it is now.  We should definitely _not_ simply throw away
this achievement.

I see that some parts of cl-lib are not well documented, and there are
problems when debugging it's stuff.  But honestly, other parts of Emacs
have the same problems.  And the Edebug support of cl stuff has also
improved in the last time - this is possible (this question only applies
to macros anyway).  FWIW, just as a random opinion, I found the original
sparse documentation of `pcase' very fine (and yes, I understood it),
so, please note, we are different people having a different background.
Please, let's discuss this with a bit tolerance and a bit less anger and
sarcasm.  It is an important decision.

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).  Why not split it up?  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.

But I don't see a necessity to, for example, kick keyword support out of
reach for the Emacs code base because, there are still, few, use cases
where it fits.  We don't want to end in a situation where we have 15
places that all reinvent the same wheel in subtly different ways.  This
would not be an improvement.  There is no need to reinvent at all.  This
stuff is well tested and integrated.  As long as the fundamental
guideline is clear that using such features is limited to spare
situations where it really makes things simpler, I don't see a problem,
apart maybe from the fact that 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? - that has
actually been one of my main questions when following this thread).


Michael.