emacs-bug-tracker
[Top][All Lists]
Advanced

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

[debbugs-tracker] bug#32979: closed (27.0.50; Oddity in #'keywordp comme


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#32979: closed (27.0.50; Oddity in #'keywordp comments.)
Date: Mon, 08 Oct 2018 20:21:02 +0000

Your message dated Mon, 08 Oct 2018 23:20:10 +0300
with message-id <address@hidden>
and subject line Re: bug#32979: 27.0.50; Oddity in #'keywordp comments.
has caused the debbugs.gnu.org bug report #32979,
regarding 27.0.50; Oddity in #'keywordp comments.
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
32979: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=32979
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: 27.0.50; Oddity in #'keywordp comments. Date: Sun, 7 Oct 2018 23:03:25 +0100
When I read the source for the Lisp function #'keywordp, in data.c, I
encounter the following:

/* 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.


In GNU Emacs 27.0.50 (build 1, i386-apple-darwin10.8.0, NS appkit-1038.36 
Version 10.6.8 (Build 10K549))
 of 2018-08-25 built on bonbon
Repository revision: 161139a42c02cce051c51fb80c6ae00c9e6beaa6
Windowing system distributor 'Apple', version 10.3.1038
System Description:  Mac OS X 10.6.8

Recent messages:
Mark set [2 times]
Entering debugger...
Back to top level
Quit
s-< is undefined
C-x C-g is undefined
Mark set [2 times]
Mark saved where search started
Quit
Mark set

Configured using:
 'configure CC=gcc-4.2 CFLAGS=-fobjc-exceptions
 PKG_CONFIG_PATH=/usr/pkg/lib/pkgconfig:/X11/lib/pkgconfig'

Configured features:
RSVG IMAGEMAGICK DBUS NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS
NS THREADS LCMS2

Important settings:
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: C/*l

Minor modes in effect:
  diff-auto-refine-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml
mml-sec password-cache epa derived epg epg-config gnus-util rmail
rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils misearch multi-isearch vc-git diff-mode
easy-mmode cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs thingatpt find-func help-fns radix-tree
cl-print debug backtrace help-mode easymenu cl-loaddefs cl-lib elec-pair
time-date tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/ns-win ns-win ucs-normalize mule-util
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind kqueue cocoa ns lcms2 multi-tty
make-network-process emacs)

Memory information:
((conses 8 238509 10624)
 (symbols 24 23285 1)
 (strings 16 38140 2495)
 (string-bytes 1 1151011)
 (vectors 12 40088)
 (vector-slots 4 878428 30532)
 (floats 8 55 214)
 (intervals 28 1547 405)
 (buffers 536 17))

-- 
‘As I sat looking up at the Guinness ad, I could never figure out /
How your man stayed up on the surfboard after forty pints of stout’
(C. Moore)



--- End Message ---
--- Begin Message --- Subject: Re: bug#32979: 27.0.50; Oddity in #'keywordp comments. Date: Mon, 08 Oct 2018 23:20:10 +0300
> From: Aidan Kehoe <address@hidden>
> 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.


--- End Message ---

reply via email to

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