GNU bug report logs -
#76476
Make cl-first, cl-second, ..., cl-tenth part of Emacs Lisp
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 76476 in the body.
You can then email your comments to 76476 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
monnier <at> iro.umontreal.ca, eliz <at> gnu.org, acorallo <at> gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#76476
; Package
emacs
.
(Fri, 21 Feb 2025 18:42:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Kangas <stefankangas <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
monnier <at> iro.umontreal.ca, eliz <at> gnu.org, acorallo <at> gnu.org, bug-gnu-emacs <at> gnu.org
.
(Fri, 21 Feb 2025 18:42:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Severity: wishlist
I propose making the following functions from cl-lib.el a part of
Emacs Lisp proper (i.e. defined in subr.el):
first
second
third
fourth
fifth
sixth
seventh
eight
ninth
tenth
rest
This would allow converting code such as:
(mapcar (lambda (thing) (car (cdr (cdr (cdr thing))))) ...)
(mapcar (lambda (thing) (cadddr thing)) ...)
(mapcar (lambda (thing) (nth 3 thing)) ...)
to the IMHO, more direct and readable:
(mapcar #'fourth ...)
I'm adding `rest' to the list as well, as the natural corollary to
`first'.
Which would be used is obviously situational, and should be left to
whoever is touching that code. There is no general need to "upgrade"
old code to prefer these new functions.
Thoughts?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76476
; Package
emacs
.
(Fri, 21 Feb 2025 20:40:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 76476 <at> debbugs.gnu.org (full text, mbox):
> Severity: wishlist
>
> I propose making the following functions from cl-lib.el a part of
> Emacs Lisp proper (i.e. defined in subr.el):
>
> first
> second
> third
> fourth
> fifth
> sixth
> seventh
> eight
> ninth
> tenth
> rest
>
> This would allow converting code such as:
>
> (mapcar (lambda (thing) (car (cdr (cdr (cdr thing))))) ...)
> (mapcar (lambda (thing) (cadddr thing)) ...)
> (mapcar (lambda (thing) (nth 3 thing)) ...)
Aka (mapcar #'cadddr ...) ;-)
> to the IMHO, more direct and readable:
>
> (mapcar #'fourth ...)
>
> I'm adding `rest' to the list as well, as the natural corollary to
> `first'.
>
> Which would be used is obviously situational, and should be left to
> whoever is touching that code. There is no general need to "upgrade"
> old code to prefer these new functions.
>
> Thoughts?
Since you asked...
There are about 8 zillion things in cl-* that it would
be more useful to add to Elisp (without prefix `cl-')
than those functions.
That said, it wouldn't hurt to add those functions, but
why not do something more useful while you're at it?
E.g., something like cl-case (sans cl-) should have been
added to Elisp eons ago. (And in fact if you loaded
cl.el you got it as `case', not `cl-case', originally.)
Better to look for more useful parts of cl-lib...
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76476
; Package
emacs
.
(Fri, 21 Feb 2025 22:32:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 76476 <at> debbugs.gnu.org (full text, mbox):
> I propose making the following functions from cl-lib.el a part of
> Emacs Lisp proper (i.e. defined in subr.el):
>
> first
> second
> third
> fourth
> fifth
> sixth
> seventh
> eight
> ninth
> tenth
> rest
FWIW, I hate those even more than the `cadar` thingies. 🙂
For direct calls, `nth` is always a better choice (except for `first`
and `rest`, of course, where `car/cdr` would be the replacement), so the
only use case is when you pass them as arg somewhere, but that doesn't
seem to be very frequent.
[ And for those rare cases, an approach like llama's (##nth N %) is
a more general solution to the problem. ]
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76476
; Package
emacs
.
(Sun, 23 Feb 2025 17:58:01 GMT)
Full text and
rfc822 format available.
Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier via "Bug reports for GNU Emacs, the Swiss
army knife of text editors" <bug-gnu-emacs <at> gnu.org> writes:
>> I propose making the following functions from cl-lib.el a part of
>> Emacs Lisp proper (i.e. defined in subr.el):
>>
>> first
>> second
>> third
>> fourth
>> fifth
>> sixth
>> seventh
>> eight
>> ninth
>> tenth
>> rest
>
> FWIW, I hate those even more than the `cadar` thingies. 🙂
>
> For direct calls, `nth` is always a better choice (except for `first`
> and `rest`, of course, where `car/cdr` would be the replacement), so the
> only use case is when you pass them as arg somewhere, but that doesn't
> seem to be very frequent.
I like these for the case where something returns a sequence
and the documentation (particularly docstrings) refers to
"the third element is...". In this situation, nth being
zero-indexed makes off-by-one errors more likely.
--
Howard
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76476
; Package
emacs
.
(Mon, 24 Feb 2025 12:11:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 76476 <at> debbugs.gnu.org (full text, mbox):
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> > first
> > second
> > third
> > fourth
> > fifth
> > sixth
> > seventh
> > eight
> > ninth
> > tenth
> > rest
> FWIW, I hate those even more than the `cadar` thingies. 🙂
I agree -- most of these are no improvement. They don't make programs
simpler.
We no longer have a need to strain to keep the number of function
names in GNU Emacs as small as possible. But that doesn't mean
we should add every function that could be meaningful.
Some meaningful functions are not worth the work of documenting them.
--
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#76476
; Package
emacs
.
(Mon, 24 Feb 2025 16:04:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 76476 <at> debbugs.gnu.org (full text, mbox):
There are about 8 zillion things in cl-* that it would
be more useful to add to Elisp (without prefix `cl-')
than those functions.
I am also curious about why these things are being added? What for?
They (as several people have mentioned) do not make code easier to
read, and we already had a quite debacle about this CLification.
That said, it wouldn't hurt to add those functions, but
why not do something more useful while you're at it?
E.g., something like cl-case (sans cl-) should have been
added to Elisp eons ago. (And in fact if you loaded
cl.el you got it as `case', not `cl-case', originally.)
INCF.
Better to look for more useful parts of cl-lib...
Reply sent
to
Stefan Kangas <stefankangas <at> gmail.com>
:
You have taken responsibility.
(Mon, 24 Feb 2025 16:34:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Stefan Kangas <stefankangas <at> gmail.com>
:
bug acknowledged by developer.
(Mon, 24 Feb 2025 16:34:01 GMT)
Full text and
rfc822 format available.
Message #25 received at 76476-done <at> debbugs.gnu.org (full text, mbox):
Richard Stallman <rms <at> gnu.org> writes:
> > > first
> > > second
> > > third
> > > fourth
> > > fifth
> > > sixth
> > > seventh
> > > eight
> > > ninth
> > > tenth
> > > rest
>
> > FWIW, I hate those even more than the `cadar` thingies. 🙂
>
> I agree -- most of these are no improvement. They don't make programs
> simpler.
>
> We no longer have a need to strain to keep the number of function
> names in GNU Emacs as small as possible. But that doesn't mean
> we should add every function that could be meaningful.
> Some meaningful functions are not worth the work of documenting them.
Thanks. It appears that this change isn't gaining much support.
I'm therefore closing this bug report now.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 25 Mar 2025 11:24:19 GMT)
Full text and
rfc822 format available.
This bug report was last modified 142 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.