From: Eli Zaretskii <eliz@gnu.org>
To: Aidan Kehoe <kehoea@parhasard.net>
Cc: 32979-done@debbugs.gnu.org
Subject: bug#32979: 27.0.50; Oddity in #'keywordp comments.
Date: Mon, 08 Oct 2018 23:20:10 +0300 [thread overview]
Message-ID: <83k1msyyv9.fsf@gnu.org> (raw)
In-Reply-To: <5bba.82ad.afd6b.dba0@parhasard.net> (message from Aidan Kehoe on Sun, 7 Oct 2018 23:03:25 +0100)
> From: Aidan Kehoe <kehoea@parhasard.net>
> Date: Sun, 7 Oct 2018 23:03:25 +0100
>
> /* Define this in C to avoid unnecessarily consing up the symbol
> name. */
> DEFUN ("keywordp", Fkeywordp, Skeywordp, 1, 1, 0,
> doc: /* Return t if OBJECT is a keyword.
> This means that it is a symbol with a print name beginning with `:'
> interned in the initial obarray. */)
> (Lisp_Object object)
> {
> if (SYMBOLP (object)
> && SREF (SYMBOL_NAME (object), 0) == ':'
> && SYMBOL_INTERNED_IN_INITIAL_OBARRAY_P (object))
> return Qt;
> return Qnil;
> }
>
> It's completely reasonable to implement the #'keywordp predicate in C given
> the internal GNU Emacs approach to keywords. The equivalent Lisp
> implementation of:
>
> (defun keywordp (object)
> (and object (symbolp object) (eq ?: (aref (symbol-name object) 0))
> (eq object (intern-soft (symbol-name object) obarray))))
>
> involves a hash table lookup after a Lisp funcall, and checking #'keywordp
> should be cheap. The comment, however, has nothing to do with anything, there
> is no consing or other dynamic memory allocation at any point, neither in the
> obvious Lisp implementation, the old cl-compat.el implementation of 20.7, nor
> the current code. The comment should be removed.
I think the author of the code thought that symbol-name conses a
string. (At some distant point in the past, aref worked in bytes, not
in characters, and the internal representation of text was not yet
superset of UTF-8, so we couldn't assume that if the first byte is
':', so is the first character, and needed to use substring instead.
But that was fixed a year before keywordp got coded in C, so that was
unlikely to be the reason for the comment.)
I removed the comment. Thanks for bringing this to our attention.
prev parent reply other threads:[~2018-10-08 20:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-07 22:03 bug#32979: 27.0.50; Oddity in #'keywordp comments Aidan Kehoe
2018-10-08 20:20 ` Eli Zaretskii [this message]
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=83k1msyyv9.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=32979-done@debbugs.gnu.org \
--cc=kehoea@parhasard.net \
/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).