help-gnu-emacs
[Top][All Lists]
Advanced

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

Lisp help: problem with uninterned symbols


From: Lars Brinkhoff
Subject: Lisp help: problem with uninterned symbols
Date: 12 Dec 2003 15:46:53 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

Hello,

I have a problem with symbols that aren't interned in any Emacs
obarray.  I intern the symbols in my own tables, but I would still
like to have the symbols as constants in my code, and have them
compare eq as usual.

Here is a simplified version of my code:

    ;;; file my-intern.el
    (defvar symbol-table nil)
    (defun my-intern (string)
      (let ((x (assoc string symbol-table)))
        (if x
            (cdr x)
            (let ((sym (make-symbol string)))
              (push (cons string sym) symbol-table)
              sym))))

Now, to include my-interned symbols as constants, I may use a macro or
eval-when-compile:

  ;;; file foobar.el
  (defun foo () (eval-when-compile (my-intern "foo")))
  (defun bar () (eval-when-compile (my-intern "foo")))

If I load this file and call (eq (foo) (bar)), the result is t as I
like.  However, if I compile the file the result is:

  ;;; file foobar.elc
  [...]
  (defalias 'foo #[nil "\300\207" [#1=#:foo] 1])
  (defalias 'bar #[nil "\300\207" [#1=#:foo] 1])

As you can see, there are two non-eq #:foo in the compiled code, so
(eq (foo) (bar)) will return nil.

If I trick the byte compiler into compiling the functions as one
top-level form, say like

  ;;; file foobar.el
  (let ()
    (defun foo () (eval-when-compile (my-intern "foo")))
    (defun bar () (eval-when-compile (my-intern "foo"))))

the result is:

  ;;; file foobar.elc
  [...]
  (byte-code "\300\301M\210\302\303M\207"
             [foo #[nil "\300\207" [#1=#:foo] 1] bar #[nil "\300\207" [#1#] 1]]
             2)

Here, there's only one #:foo which is referenced a second time with
#1#.  Great, (eq (foo) (bar)) works again.  However, that trick
doesn't work if foo and bar are defined in two separate file.

Any idea how to solve this?

-- 
Lars Brinkhoff,         Services for Unix, Linux, GCC, HTTP
Brinkhoff Consulting    http://www.brinkhoff.se/





reply via email to

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