bug#40968: 28.0.50; (apply nil)

[Pip Cet <pipcet@gmail.com>]

On Wed, May 6, 2020 at 3:28 PM Stefan Kangas <stefan@marxist.se> wrote:
> Pip Cet <pipcet@gmail.com> writes:
> > Is the function signature relevant for anything but eldoc?
>
> Besides the docstring, the manual documents it.  The suggested form is
> unusual and makes it harder to understand, IMHO.

I think it's hard to understand Elisp apply from a standard signature,
because it's really

(apply FUNCTION &rest INDIVIDUAL-ARGUMENTS ARGUMENT-LIST)

or

(apply FUNCTION-AND-ARGUMENT-LIST)

The latter (which takes a single argument) is not a special case of
the former (which takes 2,3,4,... arguments).

> >> apply is fundamental to Lisp, and has been defined like this for a
> >> long time.
> >
> > I don't know about that. Anything but the two-argument form of apply
> > strikes me as rather dialect-dependent, but I may be wrong.
>
> If I understand correctly, you propose a three argument form:
>
>     (apply FUNCTION ARGUMENT &rest ARGUMENTS)

That's a 2,3,4...-argument form.

> This is what I find unusual.  It should really be either
>
>     (apply FUNCTION &rest ARGUMENTS)

That's a 1,2,3...-argument form.

> or
>
>     (apply FUNCTION ARGUMENTS)

That's a 2-argument form.

> But since we already have the former, we are better to stick with
> that.
>
> Maybe there's a case to be made for a syntactic alternative to "&rest"
> which disallows nil, which I guess is the issue here?  But we can also
> just signal an error in this case.
>
> Racket does the latter, as one data point:
>
>     > (define foo (lambda () 1))
>     > (apply foo nil)
>     ; nil: undefined;
>     ;  cannot reference an identifier before its definition
>     ;   in module: top-level
>     ; [,bt for context]

Doesn't that just say that "nil" isn't a valid Racket identifier?
(apply foo '()) works fine, and Racket's apply requires at least two
arguments if I'm reading the error message correctly.

> BTW, I don't see a big difference conceptually between '&rest
> ARGUMENTS' and 'ARGUMENTS'.  The former is just syntactic sugar,
> right?

Not really, no.

> >> See the definition of "The Universal S-Function apply" in
> >> John McCarthy's paper: [1]
> >>
> >>     apply[f;args] =eval[cons[f;appq[args]];NIL],
> >
> > I must admit I don't know how appq is defined.

(It turns out my PDF viewer just refused to highlight the definition
right there on the page).

> My point is mainly that it has two arguments: f and args.

I think we're all in agreement about 2-argument apply.
3,4,...-argument apply is an unfortunate legacy but one we're stuck
with now. 1-argument apply is the issue here.