From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: Do we need C's extern in Emacs Lisp?
Date: Thu, 31 Mar 2022 20:59:36 +0000 [thread overview]
Message-ID: <YkYWOMYz1AGQIN7r@ACM> (raw)
In-Reply-To: <jwvsfr079kd.fsf-monnier+emacs@gnu.org>
Hello, Stefan.
On Tue, Mar 29, 2022 at 17:09:10 -0400, Stefan Monnier wrote:
> > For example, if
> > (defvar foo)
> > is in a Lisp file, then subsequent use of foo will generate an unknown
> > variable warning.
> That's not my experience. Do you have a recipe?
This happened in an attempt to fix bug #21466, a bug you opened in 2015
proposing to replace cc-bytecomp-defun and cc-bytecomp-defvar by
(declare-function foo nil) and (defvar foo).
I was wrong about the "subsequent use ... generate an unknown variable
warning.". Sorry. The problem happened during a more unusual
compilation situation best explained by the following comment from
cc-fonts.el:
;; Need to declare these local symbols during compilation since
;; they're referenced from lambdas in `byte-compile' calls that are
;; executed at compile time. They don't need to have the proper
;; definitions, though, since the generated functions aren't called
;; during compilation.
The "need to declare" means "need to give the value/function cell of the
symbol a binding", because the byte compiler seems to use boundp and
fboundp to check whether to emit "not known" warnings.
> > For example(2), if in the Lisp file there is
> > (declare-function foo nil)
> > , this generates a warning when the function foo is later defined.
> I haven't verified that it's indeed the case, but it sounds likely,
> indeed. We could consider silencing this warning, but I wonder why
> you'd put such a `declare-function` in the same file where you define
> `foo`, since it's redundant anyway.
In the above cc-fonts.el scenario, foo needs a function binding at the
time the `byte-compile' form processes it, which happens to be before it
gets defined in the file.
> Do you have a good use-case for it?
See above. ;-) It may well be that such facilities would enable me to
dismantle large parts of cc-bytecomp.el sooner rather than later.
"This variable/function is defined somewhere" is a natural thing to want
to say. The (defvar foo) and (declare-function foo nil) don't say this,
exactly.
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).
next prev parent reply other threads:[~2022-03-31 20:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-29 17:45 Do we need C's extern in Emacs Lisp? Alan Mackenzie
2022-03-29 21:09 ` Stefan Monnier
2022-03-31 20:59 ` Alan Mackenzie [this message]
2022-03-31 21:16 ` Stefan Monnier
2022-03-31 4:26 ` Richard Stallman
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YkYWOMYz1AGQIN7r@ACM \
--to=acm@muc.de \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.