Subject: bug#15880: Compute C declarations for DEFSYMs automatically.

From: Stefan Monnier <[email-masked]>
Date: Wed, 13 Nov 2013 19:26:08 -0500

>> I was thinking of doing it only for the DEFSYMs (which would obviously
>> need to be kept in a separate file).
> There still might be problems with existing symbols that are not
> DEFSYMed.  For example, suppose we add 'DEFSYM (Qprotected_field,
> "protected-field");' to window.c.  The new include file will be rebuilt
> and only window.c will be recompiled, and 'make' will succeed.  But
> buffer.c (which declares Qprotected_field as a static var and
> defines it by hand) will disagree with window.c about where
> Qprotected_field is, so Emacs might not work right, and the
> problems might be hard to find and diagnose.

Doesn't sound like a serious problem to me.  The two variables have the
same name and same content and are read-only, so the redundancy is harmless.

> Second, preallocate each DEFSYM's struct Lisp_Symbol, so that its
> address is known at link-time.

Not sure the performance impact would be significant.  But I'm not
opposed to such a change.

As for the other change: ideally, I'd like to get rid of DEFSYM and
introduce instead a new macro that would replace:

         ... Qfoo_bar ...

      syms_of_bar ()
      {
        ...
        DEFSYM (Qfoo_bar, "foo-bar");
        ...
      }

with

         ... INTERN ("foo-bar") ...

      syms_of_bar ()
      {
        ...
        /* nothing here */
        ...
      }

Now, I don't think we could do it with INTERN("foo-bar").  But we could
probably do it with:

         ... INTERN (Qfoo_bar) ...

      syms_of_bar ()
      {
        ...
        /* nothing here */
        ...
      }

such that make-docfile finds the "INTERN", infers the Lisp name from the
C name and writes a "syms.c" file which does little else but initialize
all those symbols.

        Stefan