bug#40968: 28.0.50; (apply nil)

[Phil Sainty <psainty@orcon.net.nz>]

On 2020-05-06 23:49, Pip Cet wrote:
> Again, I'm no longer sure what the right thing to do here is.  I think
> I'm up to five different interpretations of (apply ARG) here,
> depending on whether ARG is interpreted as FUNCTION, the last of the
> ARGUMENTS, an ARGUMENT but not the last one, or a combination thereof,
> and whether ARG is required to be a list or not...

To my mind the nicest change would be to handle the two error cases,
and keep everything else the same.

1. (apply nil) would signal an error.

2. (apply FUNC) would be equivalent to funcall, rather than signalling
    an error, when (functionp FUNC) -- or perhaps just (not (consp 
FUNC)).

3. (apply LIST) would remain equivalent to (apply (car LIST) (cdr LIST))


I don't feel strongly about #2.  It seems like a nice enhancement to me,
but if others feel that would be cause problems then I wouldn't argue.
Existing uses of that in the wild are obviously signalling errors at
present, so offhand it doesn't seem to me like a dangerous change, and
it would match the existing signature.

#3 just seems like the only useful thing that apply could possibly do
with a single list argument, so I'd definitely keep that.

#2 and #3 are surely both convenient for generated code which doesn't
know how many arguments it's going to be dealing with.


I would still use (FUNCTION &optional ARGS) as the signature, and just
document what happens when FUNCTION is actually a list.


-Phil