all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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).



  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.