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

Previous Next

Full log

Message #34 received at 29165 <at> debbugs.gnu.org (full text, mbox):

From: Ken Raeburn <raeburn <at> permabit.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: Philipp Stephani <p.stephani2 <at> gmail.com>, 29165 <at> debbugs.gnu.org,
 Drew Adams <drew.adams <at> oracle.com>,
 Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: Re: bug#29165: 26.0.90; can't use some code byte-compiled under emacs
 24
Date: Mon, 6 Nov 2017 14:10:27 -0500

[Message part 1 (text/plain, inline)]

On Nov 6, 2017, at 13:10, Andreas Schwab <schwab <at> linux-m68k.org> wrote:

> On Nov 06 2017, Ken Raeburn <raeburn <at> permabit.com <mailto:raeburn <at> permabit.com>> wrote:
> 
>> On Nov 6, 2017, at 09:40, Drew Adams <drew.adams <at> oracle.com> wrote:
>> 
>>>>>> We should perhaps put something about throwing error on '&option &rest'
>>>>>> into NEWS though.
>>>>> 
>>>>> I don't understand.  In Common Lisp it is perfectly correct
>>>>> to use both &optional and &rest.
>>>> 
>>>> What's rejected is (&optional &rest other-vars), whereas (&optional
>>>> var1 &rest other-vars) is okay. Does CL accept the first form (and if
>>>> yes, what does it mean)? I couldn't tell from the page you linked to.
>>> 
>>> CL accepts a single variable after &rest. And there must be
>>> a variable after &optional.  (&optional foo &rest bar) is OK.
>>> 
>>> (&optional &rest foo) is not OK.
>>> (&optional foo &rest bar toto titi) is not OK.
>> 
>> Is this CL in general or a particular CL implementation? The web page you sent the URL for earlier reads like a specification, and from its use of “*” looks to me like it allows the (admittedly useless) form of &optional with no variables.
> 
> clisp accepts it.

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’s the .elc file generated by the older Emacs that’s causing me a problem. The (new?) checks are incompatible with the the old compiled file, even though the Lisp code itself *appears* to be acceptable still.

[Message part 2 (text/html, inline)]

Previous Next

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