unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: John Wiegley <jwiegley@gmail.com>
To: Alan Mackenzie <acm@muc.de>
Cc: Marcin Borkowski <mbork@amu.edu.pl>,
	4845@debbugs.gnu.org, Helmut Eller <eller.helmut@gmail.com>
Subject: bug#4845: 23.1.50; Uninterned symbols in .elc files
Date: Tue, 19 Jan 2016 09:26:14 -0800	[thread overview]
Message-ID: <m28u3lpjk9.fsf@newartisans.com> (raw)
In-Reply-To: <20160119123956.32358.qmail@mail.muc.de> (Alan Mackenzie's message of "19 Jan 2016 12:39:56 -0000")

[-- Attachment #1: Type: text/plain, Size: 2584 bytes --]

>>>>> Alan Mackenzie <acm@muc.de> writes:

>>> (defmacro foo ()
>>> (let ((sym (make-symbol "bar")))
>>> `(progn
>>> (defun ,sym () (message "function %s called" ',sym))
>>> (,sym))))
>>> 
>>> (foo)

>>> However loading the corresponding compiled file signals an error:

shell> emacs -Q -batch -eval '(byte-compile-file "x.el")' -load x.elc
>>> Wrote /tmp/x.elc
>>> Symbol's function definition is void: bar

This example becomes clearer if we use `gensym' instead of `make-symbol
"bar"`.  Here is a macro expansion:

Byte-compiled:

  (progn
    (defun bar68503 nil
      (message "function %s called" '#:bar68503))
    (#:bar68503))

Interpreted:

  (progn
    (defun bar68503 nil
      (message "function %s called" 'bar68503))
    (bar68503))

What's happening here is this:

  1. At compile-time, we're creating a new, uninterned symbol, and we are
     both passing that symbol to defun, and calling it.

  2. `defun', at compilation time, is using the _name_ of that symbol to
     define a function definition for an interned symbol of the same name.

  3. We then try to print and call the uninterned symbol directly. So what we
     are calling, and what defun defined, are not the same symbol.

This works when non-byte-compiled because we don't inline the symbol
reference, making it a reference by name instead of by value. You can trigger
the same error behavior at interpretation time with:

  (defmacro foo ()
    (let ((sym (gensym)))
      `(progn
         (defun ,sym () (message "function %s called" ',sym))
         (funcall (symbol-function (quote ,sym))))))
  
  (foo)

I don't think this is a bug, rather macro expansion doing exactly what it was
told to do. If anything, it's odd that when interpreting, we expand to a
reference by name; but I suppose that makes sense too, given the more dynamic
nature of interpreted code.

The general rule to follow is: Don't leak internal symbols. If you use
`gensym' or `make-symbol', ensure that all dependencies on that symbol occur
entirely within the macro body. `defun' is used to establish global
definitions, so it effectively "exports" the internal symbol, breaking the
abstraction. That it has inconsistent behavior here is due to differences in
the way that byte-compilation inlines references.

I recommend closure of this bug as expected behavior, unless there are further
concerns.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

  reply	other threads:[~2016-01-19 17:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-01  8:25 bug#4845: 23.1.50; Uninterned symbols in .elc files Helmut Eller
2016-01-17 21:12 ` Marcin Borkowski
     [not found] ` <mailman.2481.1453074610.843.bug-gnu-emacs@gnu.org>
2016-01-19 12:39   ` Alan Mackenzie
2016-01-19 17:26     ` John Wiegley [this message]
2016-01-19 19:15       ` Michael Heerdegen
2016-02-20  6:23         ` John Wiegley
2016-02-20 10:01         ` Andreas Schwab
2016-01-19 19:44       ` Helmut Eller
2016-01-19 20:16         ` John Wiegley
2020-11-19  2:41           ` Stefan Kangas

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=m28u3lpjk9.fsf@newartisans.com \
    --to=jwiegley@gmail.com \
    --cc=4845@debbugs.gnu.org \
    --cc=acm@muc.de \
    --cc=eller.helmut@gmail.com \
    --cc=johnw@gnu.org \
    --cc=mbork@amu.edu.pl \
    /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).