GNU bug report logs - #73886
29.4; Confusing info about void function cells in Emacs Lisp manual

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#73886: closed (29.4; Confusing info about void function cells
 in Emacs Lisp manual)
Date: Sun, 27 Oct 2024 11:19:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sun, 27 Oct 2024 13:17:54 +0200
with message-id <864j4xaj6l.fsf <at> gnu.org>
and subject line Re: bug#73886: 29.4; Confusing info about void function cells in Emacs Lisp manual
has caused the debbugs.gnu.org bug report #73886,
regarding 29.4; Confusing info about void function cells in Emacs Lisp manual
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
73886: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73886
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Ulrich Müller <ulm <at> gentoo.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.4; Confusing info about void function cells in Emacs Lisp manual
Date: Sat, 19 Oct 2024 16:37:33 +0200

Section 13.9 "Accessing Function Cell Contents" of the GNU Emacs Lisp
Reference Manual emphasizes the distinction between void and nil
in function cells:

|    Note that void is not the same as ‘nil’ or the symbol ‘void’.
| The symbols ‘nil’ and ‘void’ are Lisp objects, and can be stored into
| a function cell just as any other object can be (and ‘void’ can be a
| valid function if you define it with ‘defun’).  A void function cell
| contains no object whatsoever.

|    You can test the voidness of a symbol's function definition with
| ‘fboundp’.  After you have given a symbol a function definition, you
| can make it void once more using ‘fmakunbound’.

Also, for "fboundp":

|      This function returns ‘t’ if the symbol has an object in its
|      function cell, ‘nil’ otherwise.  It does not check that the
|      object is a legitimate function.

It seems that the actual behavior does not reflect this, i.e. there
is no distinction between nil and void:

   (fmakunbound 'foo)
   (fboundp 'foo) ⇒ nil

   (fset 'foo nil)
   ;; according to the manual, the following should return t
   ;; because nil is a Lisp object:
   (fboundp 'foo) ⇒ nil

Is the manual wrong, or am I missing something?

[Message part 3 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: ulm <at> gentoo.org, 73886-done <at> debbugs.gnu.org
Subject: Re: bug#73886: 29.4; Confusing info about void function cells in
 Emacs Lisp manual
Date: Sun, 27 Oct 2024 13:17:54 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: ulm <at> gentoo.org,  73886 <at> debbugs.gnu.org
> Date: Sun, 20 Oct 2024 12:56:03 -0400
> 
> >> Oops.  Looks like I missed this part when I changed it back around
> >> Emacs-24.4:
> >> 
> >>     ** In 'symbol-function', nil and "unbound" are indistinguishable.
> >>     'symbol-function' does not signal a 'void-function' error any more.
> >>     To determine if a symbol's function definition is void, use 'fboundp'.
> >
> > Could you explain the rationale for that change?  I tried to look for
> > relevant discussions around that date, but came up empty-handed.
> 
> I can't remember discussing it, no.  It was a kind of "executive
> decision".
> 
> Having a special "void" (`Qundefined`) non-value for the `symbol-value`
> is needed for `boundp` since variables can contain *any* value, but not
> for the `symbol-function` part where we can use any normal value (I
> chose `nil`) to play this role as long as it doesn't collide with values
> normally held in the `symbol-function` slot, like function names,
> function values, cons cells, vectors, ...
> 
> The upside was a simplification in various chunks of code which used to
> do things like `(and (fboundp SYM) (symbol-function SYM))` which can now
> be simplified to `(symbol-function SYM)`.
> 
> I remember two "motivators", i.e. places where the need to pay attention
> to the special void case annoyed me enough to look into this and make
> the change, one was `nadvice.el` and the other was `cl-letf`.
> [ So, it was no accident that the change happened in the same release as
>   the addition of `nadvice.el`.  ]
> 
> In both cases the issue is that we want to deal with "places"
> (generalized variables) and that abstraction works well for those places
> which *always* contain a value, but not as well for those special places
> that can be "unbound", so removing the "unbound" case from
> `symbol-function` resulted in a welcome simplification.
> For the same reason I dislike EIEIO's notion of `slot-boundp` and have
> already considered marking it obsolete.

Thanks, I've now updated the documentation, and I'm closing this bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.