From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.bugs Subject: 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-ID: References: <6eh8u7x5be.fsf@just-testing.permabit.com> <87375r7f0g.fsf@users.sourceforge.net> <9f1e7a1f-bfc0-43a4-9acb-cf69b85587be@default> <5C8038D7-FF85-4C42-A728-F3F85CDAC85C@permabit.com> <87efpb46sp.fsf@linux-m68k.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_EBF5DDDC-A799-493D-9E98-5221A84C7772" X-Trace: blaine.gmane.org 1509995478 469 195.159.176.226 (6 Nov 2017 19:11:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 6 Nov 2017 19:11:18 +0000 (UTC) Cc: Philipp Stephani , 29165@debbugs.gnu.org, Noam Postavsky To: Andreas Schwab Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 06 20:11:11 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBmnf-0008E0-Ar for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Nov 2017 20:11:11 +0100 Original-Received: from localhost ([::1]:49884 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eBmnm-0008Q7-L6 for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Nov 2017 14:11:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53278) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eBmna-0008Oo-3t for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2017 14:11:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eBmnW-0004SP-Sk for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2017 14:11:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45874) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eBmnW-0004Rb-M1 for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2017 14:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eBmnW-0000bO-Az for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2017 14:11:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ken Raeburn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Nov 2017 19:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29165 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug Original-Received: via spool by 29165-submit@debbugs.gnu.org id=B29165.15099954372278 (code B ref 29165); Mon, 06 Nov 2017 19:11:02 +0000 Original-Received: (at 29165) by debbugs.gnu.org; 6 Nov 2017 19:10:37 +0000 Original-Received: from localhost ([127.0.0.1]:54555 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBmn7-0000ag-6z for submit@debbugs.gnu.org; Mon, 06 Nov 2017 14:10:37 -0500 Original-Received: from mail-qk0-f176.google.com ([209.85.220.176]:45774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBmn5-0000aT-6W for 29165@debbugs.gnu.org; Mon, 06 Nov 2017 14:10:35 -0500 Original-Received: by mail-qk0-f176.google.com with SMTP id f199so12301088qke.2 for <29165@debbugs.gnu.org>; Mon, 06 Nov 2017 11:10:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=permabit.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ScZkrFRlWLzKCDnwiXGdfIwfacdjS8GqJdRB+DNl9W4=; b=e+05dtvmwIYMv9SicB1H6PZI1t/Gwpc5Bzh6Wc+VKtDCGSK/RikeRiskBVBmwYFdDz oEeR8DXMd0fRsZdW0mni1PAtq8C/LLNNOfjuLUhKc3vzFa8XJX7tqeIFQbhOsUgGr0xV WzGyTBfxgd4hL04RpKVQbpU/wXsOfPNl3o81Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ScZkrFRlWLzKCDnwiXGdfIwfacdjS8GqJdRB+DNl9W4=; b=YX0SP4kjmw62A4/BQHzK5k1Zm/lBpfXGZ0ne7WJqS09C+V4mI/EUeL2ar5ZA+0wNB6 T3kQxQFuUTdRJYGXfdcHOLboMgoO0AoJ+9PfxyuroPtKWGxIplCIXmwOxPwjuXLq3XYt 8p9S6l2S/3I9jzr4vEqvqcg1mAOhK5lEEs8V4hZt/3nr0OAqgREbZlRtL6QBdMzpiyQM KH9BkBul7Mt5hM/MIdhc+xUtFc4mlD2UgsC2cG08KJRG+G9hg7EWQN5gnJak6ErglXmD TjyttsK/OxhkLlfXJGdX5Vs+qnBxA2Ta7bSAukhgmr61db7KEL7U3WBdpNK68v2XKm8E 57gQ== X-Gm-Message-State: AJaThX7QU4n0H0wRNe0xMFpO33x4Lij24pGbpaHRuesLupgFNWoFW7pM zDzRnFlG3dJe8kU1hT7r+yzYNA== X-Google-Smtp-Source: ABhQp+SpvbeGB9NnYvZsQiCX0Qkf4iaFCVAUWHl228y7oRHD1zuYjXDxMI5jdWLWc2y3Rv09WgNREg== X-Received: by 10.55.74.138 with SMTP id x132mr21940749qka.239.1509995429627; Mon, 06 Nov 2017 11:10:29 -0800 (PST) Original-Received: from [192.168.23.135] (c-73-253-167-23.hsd1.ma.comcast.net. [73.253.167.23]) by smtp.gmail.com with ESMTPSA id l20sm9046412qtb.27.2017.11.06.11.10.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Nov 2017 11:10:28 -0800 (PST) In-Reply-To: <87efpb46sp.fsf@linux-m68k.org> X-Mailer: Apple Mail (2.3273) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:139514 Archived-At: --Apple-Mail=_EBF5DDDC-A799-493D-9E98-5221A84C7772 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 6, 2017, at 13:10, Andreas Schwab wrote: > On Nov 06 2017, Ken Raeburn > wrote: >=20 >> On Nov 6, 2017, at 09:40, Drew Adams wrote: >>=20 >>>>>> We should perhaps put something about throwing error on '&option = &rest' >>>>>> into NEWS though. >>>>>=20 >>>>> I don't understand. In Common Lisp it is perfectly correct >>>>> to use both &optional and &rest. >>>>=20 >>>> 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. >>>=20 >>> CL accepts a single variable after &rest. And there must be >>> a variable after &optional. (&optional foo &rest bar) is OK. >>>=20 >>> (&optional &rest foo) is not OK. >>> (&optional foo &rest bar toto titi) is not OK. >>=20 >> 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 =E2=80=9C*=E2=80=9D looks to me like it allows the (admittedly = useless) form of &optional with no variables. >=20 > 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=E2=80=99= s the .elc file generated by the older Emacs that=E2=80=99s 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.= --Apple-Mail=_EBF5DDDC-A799-493D-9E98-5221A84C7772 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 6, = 2017, at 13:10, Andreas Schwab <schwab@linux-m68k.org> wrote:

On Nov 06 2017, Ken Raeburn <raeburn@permabit.com> wrote:
On Nov 6, 2017, at 09:40, = Drew Adams <drew.adams@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 =E2=80=9C*=E2=80=9D = 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=E2=80=99= s the .elc file generated by the older Emacs that=E2=80=99s 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.= --Apple-Mail=_EBF5DDDC-A799-493D-9E98-5221A84C7772--