bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24

[Ken Raeburn]

On Nov 13, 2017, at 13:06, Noam Postavsky <npostavs@users.sourceforge.net> 
wrote:

> On Mon, Nov 6, 2017 at 2:16 PM, Noam Postavsky
> <npostavs@users.sourceforge.net> wrote:
>> On Mon, Nov 6, 2017 at 2:10 PM, Ken Raeburn <raeburn@permabit.com> wrote:
>> 
>>> It appears that the emacs-26 version of defun* is happy with it (the
>>> original Lisp code I posted, using &optional &key) as well, as long as I
>>> provide the source, or a byte-compiled file from Emacs 25 or 26
>> 
>> It looks like the cl-defun in newer Emacs throws away the &optional
>> for you in this case.
> 
> I think we should make cl-defun reject this kind of code, to be
> consistent with plain defun. See attached.

I’m of two minds about it… it’s a useless but harmless degenerate case, and 
based on the link Drew posted and the test Andreas did, making it an error 
would be a gratuitous incompatibility with CL or at least one implementation.  
And maybe it’s not entirely useless if it simplifies someone’s macro so that 
they can treat zero-or-more optional variables with a single, simple common 
code path.  But even if we do make it an error, isn’t there usually a stage 
where it’s just a warning?

(And if we’re going to make that sort of thing an error, we should probably 
check whether empty &key or &aux variable lists are similarly rejected.  I 
haven’t looked.)

Also, what the CL macros do going forward is arguably a separate question from 
whether byte-code processing should reject the byte code generated for the same 
construct by older releases.  That’s what we’ve got now — Emacs 26.0.90 accepts 
the forms for CL macros but rejects them in byte code, and Emacs 24 CL macros 
produced such forms in byte code when given such forms as input.  So 
currently-acceptable code, or at least code still treated as acceptable under 
Emacs 25, when compiled by an older release, is no longer accepted. If the 
source isn’t going to be rejected (e.g., if it’s quietly accepted or only 
produces a warning), then the byte-code for it probably ought not to be 
rejected.

Ken