bug#62746: [PATCH] Updated Elispref-Manual: `nil' cannot be defuned

bug#62746: [PATCH] Updated Elispref-Manual: `nil' cannot be defuned

[Shynur Xie]

[-- Attachment #1: Type: text/plain, Size: 796 bytes --]

Original:

“The symbols nil and void are Lisp objects, and can be stored into a
 function cell just as any other object can be (and they can be valid
 functions if you define them in turn with defun).”

Updated:

“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).”

________________________________________

By the way, I've sent a Copyright Assignment Request to
<assign@gnu.org> five days ago, but there is no reply.  Is there any
additional information or action required from me?

> From: Eli Zaretskii
>
> Please email the following information to assign@gnu.org, and we
> will send you the assignment form for your past and future changes.

[-- Attachment #2: 0001-Updated-Elispref-Manual-nil-cannot-be-defuned.patch --]
[-- Type: application/octet-stream, Size: 1000 bytes --]

From 56df64a62d4d089c0b88408603f8f23e9f11aa24 Mon Sep 17 00:00:00 2001
From: Shynur <one.last.kiss@outlook.com>
Date: Fri, 7 Apr 2023 11:45:28 +0800
Subject: [PATCH] Updated Elispref-Manual: `nil' cannot be defuned

---
 doc/lispref/functions.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/lispref/functions.texi b/doc/lispref/functions.texi
index be050570458..0a4237e6cc1 100644
--- a/doc/lispref/functions.texi
+++ b/doc/lispref/functions.texi
@@ -1484,7 +1484,7 @@ Function Cells
   Note that void is not the same as @code{nil} or the symbol
 @code{void}.  The symbols @code{nil} and @code{void} are Lisp objects,
 and can be stored into a function cell just as any other object can be
-(and they can be valid functions if you define them in turn with
+(and @code{void} can be a valid function if you define it with
 @code{defun}).  A void function cell contains no object whatsoever.
 
   You can test the voidness of a symbol's function definition with
-- 
2.34.1

bug#62746: [PATCH] Updated Elispref-Manual: `nil' cannot be defuned

[Eli Zaretskii]

> From: Shynur Xie <one.last.kiss@outlook.com>
> Date: Mon, 10 Apr 2023 08:33:20 +0000
> 
> Original:
> 
> “The symbols nil and void are Lisp objects, and can be stored into a
>  function cell just as any other object can be (and they can be valid
>  functions if you define them in turn with defun).”
> 
> Updated:
> 
> “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).”

Why do you think the original text needs to be corrected?

> By the way, I've sent a Copyright Assignment Request to
> <assign@gnu.org> five days ago, but there is no reply.  Is there any
> additional information or action required from me?

If they don't reply in a week from now, ping them and CC me.

Thanks.

bug#62746: [PATCH] Updated Elispref-Manual: `nil' cannot be defuned

[Shynur Xie]

I think what the manual says is: for example, if the value stored in the function cell of symbol `my-func` is `nil` or `void`, then defining `nil` or `void` with defun makes `my-func` a valid function.

________________________________________
From: Eli Zaretskii <eliz@gnu.org>
Sent: Monday, April 10, 2023 4:49 PM
To: Shynur Xie; Stefan Monnier
Cc: 62746@debbugs.gnu.org
Subject: Re: bug#62746: [PATCH] Updated Elispref-Manual: `nil' cannot be defuned

> From: Shynur Xie <one.last.kiss@outlook.com>
> Date: Mon, 10 Apr 2023 08:33:20 +0000
>
> Original:
>
> “The symbols nil and void are Lisp objects, and can be stored into a
>  function cell just as any other object can be (and they can be valid
>  functions if you define them in turn with defun).”
>
> Updated:
>
> “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).”

Why do you think the original text needs to be corrected?

> By the way, I've sent a Copyright Assignment Request to
> <assign@gnu.org> five days ago, but there is no reply.  Is there any
> additional information or action required from me?

If they don't reply in a week from now, ping them and CC me.

Thanks.

bug#62746: [PATCH] Updated Elispref-Manual: `nil' cannot be defuned

[Eli Zaretskii]

> From: Shynur Xie <one.last.kiss@outlook.com>
> CC: "62746@debbugs.gnu.org" <62746@debbugs.gnu.org>
> Date: Mon, 10 Apr 2023 08:56:40 +0000
> 
> I think what the manual says is: for example, if the value stored in the function cell of symbol `my-func` is `nil` or `void`, then defining `nil` or `void` with defun makes `my-func` a valid function.

And why is that wrong?

bug#62746: [PATCH] Updated Elispref-Manual: `nil' cannot be defuned

[Shynur Xie]

I tried to defun `nil', but Emacs gived me an error:

```
(defmacro defun (name arglist &optional docstring &rest body)
  ...
  (or name (error "Cannot define '%s' as a function" name))
```

And sorry, I will attach the reason for my modification next time, instead of waiting for others to ask.

________________________________________
From: Eli Zaretskii <eliz@gnu.org>
Sent: Monday, April 10, 2023 5:01 PM
To: Shynur Xie
Cc: monnier@iro.umontreal.ca; 62746@debbugs.gnu.org
Subject: Re: bug#62746: [PATCH] Updated Elispref-Manual: `nil' cannot be defuned

> From: Shynur Xie <one.last.kiss@outlook.com>
> CC: "62746@debbugs.gnu.org" <62746@debbugs.gnu.org>
> Date: Mon, 10 Apr 2023 08:56:40 +0000
>
> I think what the manual says is: for example, if the value stored in the function cell of symbol `my-func` is `nil` or `void`, then defining `nil` or `void` with defun makes `my-func` a valid function.

And why is that wrong?

bug#62746: [PATCH] Updated Elispref-Manual: `nil' cannot be defuned

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> “The symbols nil and void are Lisp objects, and can be stored into a
>>  function cell just as any other object can be (and they can be valid
>>  functions if you define them in turn with defun).”
>> 
>> Updated:
>> 
>> “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).”
>
> Why do you think the original text needs to be corrected?

Indeed, `nil` is treated specially to mean "not defined" when we try to
call a function:

    Lisp_Object
    funcall_general (Lisp_Object fun, ptrdiff_t numargs, Lisp_Object *args)
    {
      Lisp_Object original_fun = fun;
     retry:
      if (SYMBOLP (fun) && !NILP (fun)
          && (fun = XSYMBOL (fun)->u.s.function, SYMBOLP (fun)))
        fun = indirect_function (fun);
    
      if (SUBRP (fun) && !SUBR_NATIVE_COMPILED_DYNP (fun))
        return funcall_subr (XSUBR (fun), numargs, args);
      else if (COMPILEDP (fun)
               || SUBR_NATIVE_COMPILED_DYNP (fun)
               || MODULE_FUNCTIONP (fun))
        return funcall_lambda (fun, numargs, args);
      else
        {
          if (NILP (fun))
            xsignal1 (Qvoid_function, original_fun);


-- Stefan

bug#62746: [PATCH] Updated Elispref-Manual: `nil' cannot be defuned

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Shynur Xie <one.last.kiss@outlook.com>,  62746@debbugs.gnu.org
> Date: Mon, 10 Apr 2023 10:14:59 -0400
> 
> >> “The symbols nil and void are Lisp objects, and can be stored into a
> >>  function cell just as any other object can be (and they can be valid
> >>  functions if you define them in turn with defun).”
> >> 
> >> Updated:
> >> 
> >> “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).”
> >
> > Why do you think the original text needs to be corrected?
> 
> Indeed, `nil` is treated specially to mean "not defined" when we try to
> call a function:
> 
>     Lisp_Object
>     funcall_general (Lisp_Object fun, ptrdiff_t numargs, Lisp_Object *args)
>     {
>       Lisp_Object original_fun = fun;
>      retry:
>       if (SYMBOLP (fun) && !NILP (fun)
>           && (fun = XSYMBOL (fun)->u.s.function, SYMBOLP (fun)))
>         fun = indirect_function (fun);
>     
>       if (SUBRP (fun) && !SUBR_NATIVE_COMPILED_DYNP (fun))
>         return funcall_subr (XSUBR (fun), numargs, args);
>       else if (COMPILEDP (fun)
>                || SUBR_NATIVE_COMPILED_DYNP (fun)
>                || MODULE_FUNCTIONP (fun))
>         return funcall_lambda (fun, numargs, args);
>       else
>         {
>           if (NILP (fun))
>             xsignal1 (Qvoid_function, original_fun);
> 

Thanks.  So I think our documentation is correct in this aspect, and
I'm therefore closing this bug.

bug#62746: [PATCH] Updated Elispref-Manual: `nil' cannot be defuned

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> >> “The symbols nil and void are Lisp objects, and can be stored into a
>> >>  function cell just as any other object can be (and they can be valid
>> >>  functions if you define them in turn with defun).”
>> >> 
>> >> Updated:
>> >> 
>> >> “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).”
>> >
>> > Why do you think the original text needs to be corrected?
>> 
>> Indeed, `nil` is treated specially to mean "not defined" when we try to
>> call a function:
>> 
>>     Lisp_Object
>>     funcall_general (Lisp_Object fun, ptrdiff_t numargs, Lisp_Object *args)
>>     {
>>       Lisp_Object original_fun = fun;
>>      retry:
>>       if (SYMBOLP (fun) && !NILP (fun)
>>           && (fun = XSYMBOL (fun)->u.s.function, SYMBOLP (fun)))
>>         fun = indirect_function (fun);
>>     
>>       if (SUBRP (fun) && !SUBR_NATIVE_COMPILED_DYNP (fun))
>>         return funcall_subr (XSUBR (fun), numargs, args);
>>       else if (COMPILEDP (fun)
>>                || SUBR_NATIVE_COMPILED_DYNP (fun)
>>                || MODULE_FUNCTIONP (fun))
>>         return funcall_lambda (fun, numargs, args);
>>       else
>>         {
>>           if (NILP (fun))
>>             xsignal1 (Qvoid_function, original_fun);
>> 
>
> Thanks.  So I think our documentation is correct in this aspect, and
> I'm therefore closing this bug.

The current text suggest that `nil` "can be valid [a]
function if you define [it] in turn with defun", which is not really true.


        Stefan

bug#62746: [PATCH] Updated Elispref-Manual: `nil' cannot be defuned

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: one.last.kiss@outlook.com,  62746-done@debbugs.gnu.org
> Date: Fri, 05 May 2023 10:01:24 -0400
> 
> > Thanks.  So I think our documentation is correct in this aspect, and
> > I'm therefore closing this bug.
> 
> The current text suggest that `nil` "can be valid [a]
> function if you define [it] in turn with defun", which is not really true.

Feel free to correct that, or suggest how to do that.

bug#62746: [PATCH] Updated Elispref-Manual: `nil' cannot be defuned

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

>> > Thanks.  So I think our documentation is correct in this aspect, and
>> > I'm therefore closing this bug.
>> 
>> The current text suggest that `nil` "can be valid [a]
>> function if you define [it] in turn with defun", which is not really true.
>
> Feel free to correct that, or suggest how to do that.

The suggest patch did just that, AFAICT.


        Stefan

bug#62746: [PATCH] Updated Elispref-Manual: `nil' cannot be defuned

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: one.last.kiss@outlook.com,  62746@debbugs.gnu.org
> Date: Fri, 05 May 2023 14:04:26 -0400
> 
> >> > Thanks.  So I think our documentation is correct in this aspect, and
> >> > I'm therefore closing this bug.
> >> 
> >> The current text suggest that `nil` "can be valid [a]
> >> function if you define [it] in turn with defun", which is not really true.
> >
> > Feel free to correct that, or suggest how to do that.
> 
> The suggest patch did just that, AFAICT.

Ah, I've misunderstood what you said.  Now fixed.