[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24
From: |
Ken Raeburn |
Subject: |
bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24 |
Date: |
Mon, 13 Nov 2017 14:42:18 -0500 |
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
- bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24, (continued)
- bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24, Noam Postavsky, 2017/11/06
- bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24, Drew Adams, 2017/11/06
- bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24, Noam Postavsky, 2017/11/06
- bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24, Drew Adams, 2017/11/06
- bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24, Philipp Stephani, 2017/11/06
- bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24, Ken Raeburn, 2017/11/06
- bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24, Andreas Schwab, 2017/11/06
- bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24, Ken Raeburn, 2017/11/06
- bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24, Noam Postavsky, 2017/11/06
- bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24, Noam Postavsky, 2017/11/13
- bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24,
Ken Raeburn <=
- bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24, Noam Postavsky, 2017/11/13
- bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24, Noam Postavsky, 2017/11/27
- bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24, Drew Adams, 2017/11/06
bug#29165: 26.0.90; can't use some code byte-compiled under emacs 24, Eli Zaretskii, 2017/11/06