GNU bug report logs - #32979
27.0.50; Oddity in #'keywordp comments.

Previous Next

Package: emacs;

Reported by: Aidan Kehoe <kehoea <at> parhasard.net>

Date: Sun, 7 Oct 2018 22:04:02 UTC

Severity: normal

Found in version 27.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #10 received at 32979-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Aidan Kehoe <kehoea <at> parhasard.net>
Cc: 32979-done <at> debbugs.gnu.org
Subject: Re: bug#32979: 27.0.50; Oddity in #'keywordp comments.
Date: Mon, 08 Oct 2018 23:20:10 +0300
> From: Aidan Kehoe <kehoea <at> 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.




This bug report was last modified 6 years and 223 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.