From: Drew Adams <drew.adams@oracle.com>
To: Philipp Stephani <p.stephani2@gmail.com>, npostavs@users.sourceforge.net
Cc: 25627@debbugs.gnu.org
Subject: bug#25627: 25.1; `help-make-xrefs' loads `cl-extra.el' now
Date: Tue, 7 Feb 2017 15:00:46 -0800 (PST) [thread overview]
Message-ID: <3abd0b72-e875-4c07-bdc2-4aa62de2c55e@default> (raw)
In-Reply-To: <CAArVCkQBuraSJ3LG0Oad2_DAgod4Uao05DscFyzMOrgAnXMgMw@mail.gmail.com>
>> > > I thought that the point of creating `cl-lib.el' was to give people a
>> > > library of the most-used CL constructs and still let them avoid loading
>> > > all of `cl.el'. If we are, in effect, loading `cl-extra.el' now nearly
>> > > by default then what's the point of separating out `cl-lib.el'?
>> >
>> > AFAIK, the point of cl-lib is to have the CL constructs in a separate
>> > namespace, so that loading cl-lib doesn't change the semantics of
>> > existing code that might not expect it (unlike cl.el).
>>
>> What part of `cl.el' changes the semantics of existing [non-cl.el]
>> code?
>
> Loading cl.el modifies the observable behavior of dolist.
Yes, such is legacy. See what I wrote about needing to fix
such problems (name clashes).
The fact that plain Emacs `dolist' is massaged to make it
DTRT for cl.el under that same name is wrong. And then
cl-macs.el leverages that advice for `cl-dolist'.
The Emacs emulation of Common-Lisp `dolist' should be called
(only) `cl-dolist' - or else the Emacs thing by that name
should be renamed to something else.
Emacs has generally opted to co-opt some names for its own
version of a behavior, instead of giving the Emacs version
a different name. Because of that we should not allow a
Common-Lisp emulation of such a thing use the same name.
It should use the `cl-' prefix, since the unprefixed name
is already taken.
Aliasing (or doing something that has the same effect, as
for `dolist') the plain name to the name with prefix `cl-'
is the wrong thing to do, in such cases. We should alias
to remove prefix `cl-' only when the result is not a name
clash.
But again, this bug report is about unnecessarily
autoloading `cl-extra.el'. It is not about `cl.el'.
next prev parent reply other threads:[~2017-02-07 23:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-05 18:44 bug#25627: 25.1; `help-make-xrefs' loads `cl-extra.el' now Drew Adams
2017-02-05 19:24 ` Drew Adams
2017-02-07 0:58 ` npostavs
2017-02-07 2:21 ` Drew Adams
2017-02-07 13:30 ` Michael Heerdegen
2017-02-07 16:13 ` Drew Adams
2017-02-07 17:19 ` Michael Heerdegen
2017-02-07 22:29 ` Philipp Stephani
2017-02-07 23:00 ` Drew Adams [this message]
2017-02-07 23:08 ` Noam Postavsky
2017-02-08 0:18 ` Drew Adams
2017-02-08 1:56 ` npostavs
2017-02-08 1:59 ` Drew Adams
2017-02-08 4:57 ` npostavs
2017-02-08 5:40 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3abd0b72-e875-4c07-bdc2-4aa62de2c55e@default \
--to=drew.adams@oracle.com \
--cc=25627@debbugs.gnu.org \
--cc=npostavs@users.sourceforge.net \
--cc=p.stephani2@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).