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

[Gerd Möllmann]

Alan Mackenzie <acm@muc.de> writes:

>> Thanks for that. I find it much easier to digest than this clean/unclean
>> thing.
>
>> And wow, that will not be popular :-).
>
> It will be a mixed popular/unpopular, with probably few people in the
> middle.  Back when you were the Maintainer, I think there was a ban on
> the use of cl.el and friends, except for at compilation time.  I don't
> think that caused any problems.

Not that I remember, but it's of course a long time ago.

But somehow, CL discussions and the clean/unclean thing from Richard
were always present. At least I seem to remember that.

>> > We should deprecate those functions/macros/variables in cl-lib that have
>> > no doc string, or a substandard one.  This includes "internal" functions,
>> > too.  Also to be deprecated are obscure functions/m/v (such as
>> > cl-labels).
>
>> Am I right in assuming that this is not about the documentation itself,
>> but just some selection criterium for reducing the size of cl-lib?
>
> The most troublesome cl-lib functions are those without adequate
> documentation.  They're the ones that waste unbounded amounts of time
> when trying to debug something which uses them.  That's why I'd like to
> do away with them.  There are few people willing to fix the doc strings
> in cl-lib, though João has volunteered to make a start.

Ok, thanks.

>> > Having done this, we recode code currently using those deprecated
>> > f/m/v.
>
>> What would recode mean? Using seq/map?
>
> I hadn't really thought of seq.el or map.el.  What do they do?

I would describe both as sets of generic functions for sequence handling
and mapping over sequences. I'm personally not using them, as I wrote here:

  https://lists.gnu.org/archive/html/emacs-devel/2023-11/msg00122.html

That spawned answers from Eli and a sub-thread from Richard, which I
personally found unconvincing.

But I'd recommend in any case that you build your own opinion.

> But it's
> clear that working code can be written without these or cl-lib.
>
>> > (Here a "substandard" doc string is contrasted with an adequate one,
>> > which does all of the following:
>> > (i) It says what the function/macro _does_, or what the variable _is_.
>> > (ii) It describes the form and meaning of each parameter, and its
>> >   relationship to (i).
>> > (iii) If the return value is significant, it describes this.
>> > (iv) It describes all effects on the global state, such as where it
>> >   writes results to, and suchlike.)
>
>> > This would reduce the size of cl-lib to something more manageable than
>> > what we have at the moment.