GNU bug report logs - #40968
28.0.50; (apply nil)

Previous Next

Full log

View this message in rfc822 format

From: Phil Sainty <psainty <at> orcon.net.nz>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 40968 <at> debbugs.gnu.org, Stefan Kangas <stefan <at> marxist.se>
Subject: bug#40968: 28.0.50; (apply nil)
Date: Thu, 07 May 2020 08:32:16 +1200

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

Previous Next

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