all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Basil L. Contovounesios" <basil@contovou.net>
To: Adam Porter <adam@alphapapa.net>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: Adding a DECLARE spec equivalent to DECLARE-FUNCTION
Date: Sat, 16 Mar 2024 11:04:56 +0100	[thread overview]
Message-ID: <87frwqqypj.fsf@epfl.ch> (raw)
In-Reply-To: <0156399d-eead-4855-8f40-8018e0efe331@alphapapa.net> (Adam Porter's message of "Sun, 3 Mar 2024 13:17:21 -0600")

Adam Porter [2024-03-03 13:17 -0600] wrote:

> In light of [this thread], this seems like a good time to propose this
> idea: to enhance the `declare' form with a `function' spec equivalent to
> the top-level `declare-function' form.  This allows keeping the
> declaration inside the function that makes it necessary, which has a few
> advantages:
>
> 1. It clearly indicates which function makes the declaration necessary
>    (i.e. which function contains calls to the function in another
>    library).
> 2. If the function is moved to another file, the declaration moves with
>    it.
> 3. If the function is removed, the declaration is removed with it.
> 4. It reduces the number of top-level forms.
>
> Also, it seems like a natural fit, i.e. `declare-function' to `(declare
> (function ...))'.
>
> Would this be an acceptable addition to Emacs Lisp?

FWIW, my vote is against such a declare spec.  Compared to other declare
specs, this one introduces the tightest coupling between a function's
property declarations and the function's body, i.e. its implementation
details.  Knowing that, at a particular point in the body, a given
function will be defined, is a local property of that particular
expression, not a global property of the containing function.

My vote is for instead teaching the compiler to treat declare-function
more like it treats defvar, in that the effect of declare-function
should be made local to the current lexical scope.  [It is already
possible to write this way, and I've been known to, but sadly the effect
is global.]  This wish has been raised and agreed on here (at least in
passing) before.

This would reap all the benefits of points 1-4, as well as an additional
one: that declare-function is lexically closer to the implementation
through which the need for the declaration arises.  I think a
declaration at the top of a function is more likely to be forgotten and
become stale as the implementation changes.

-- 
Basil



  reply	other threads:[~2024-03-16 10:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-03 19:17 Adding a DECLARE spec equivalent to DECLARE-FUNCTION Adam Porter
2024-03-16 10:04 ` Basil L. Contovounesios [this message]
2024-03-17  4:09   ` Adam Porter

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=87frwqqypj.fsf@epfl.ch \
    --to=basil@contovou.net \
    --cc=adam@alphapapa.net \
    --cc=emacs-devel@gnu.org \
    /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.