[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Lisp files that load cl-lib in problematical ways

From: Emanuel Berg
Subject: Re: Lisp files that load cl-lib in problematical ways
Date: Mon, 23 Oct 2023 14:18:51 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Alan Mackenzie wrote:

>> From my point of view in some way it does sound like that
>> some are against it [the use of cl-lib] for ideological
>> reasons rather than technical. E.g. those that makes code
>> unreadable or lets rewrite something to drop the dependency
>> to not load it.
> You seem to be saying that avoiding making code unreadable
> (i.e. difficult to maintain) is an "ideological" thing.

>From Eli we heard cl-lib adds bloat and fills up the global
namespace. From RMS and you we hear it makes code more
difficult to maintain.

At the same time Eli says it is just another Elisp package and
library which should be treated as any other, i.e. it should
only be used and brought in when needed. This, of course,
I think everyone will agree on.

But the other arguments are more difficult to see from here.
Rather than bloat and filling up the namespace unnecessarily,
I think it makes Elisp more powerful. So to me, cl-lib is
a good example och packages we do want, and the more
the merrier.

When there is no clear way to do something using non-cl-lib
Elisp, I see no harm in using cl-lib (on the contrary) and
I still don't understand why it appears to be considered OK in
some places and some stages of Emacs execution and not others.
Wherever it is useful and provides expressive and
computational power otherwise unavailable, it should be OK to
use. With the possible exception of 'emacs -Q', since there
the minimalist policy makes sense and one can make
that argument.

One can also think that cl-lib's presence can bring guys from
the Common Lisp world here, which is of course a positive
thing. And it doesn't mean now all Emacs will be Common Lisp.

> That's a big "when" you use. If the use of cl-lib actually
> did make things "easier to understand", I would agree with
> you. But it doesn't.

E.g. (cl-incf some-var) isn't better and more clean than (setq
some-var (1+ some-var)) ? I think it is! Other examples are,
as has been mentioned, `cl-decf' and `cl-pushnew'. I can see
that `cl-loop' has some higher threshold to understand and to
get used to but (1) it adds so much expressive power increase
in complexity is unavoidable and expected; and, (2) it still
should be no match for programmers maintaining Emacs?

> As an example, take the last macro in cl-macs.el,
> `cl-deftype'. Its doc string is just [...]

Well, we should improve the docstrings whenever they are
insufficient, this is the same as any other library.

>> On the other hand if it _is_ useful - and the number of
>> people using it and the number of files where it is used,
>> and the number of occurrences indicate that it is - there
>> is no reason to disencourage people from using
>> it, anywhere.
> I have outlined a reason above. Fifty years ago, you could
> have been saying the same about the goto statement.

50 years ago, some programming languages were so limited the
goto was needed. Today, some are so powerful, one can add
cl-lib to make them even better. And indeed, we now have
`cl-return', even ;)

underground experts united

reply via email to

[Prev in Thread] Current Thread [Next in Thread]