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 12:25:24 -0500 Message-ID: <5C8038D7-FF85-4C42-A728-F3F85CDAC85C@permabit.com> References: <6eh8u7x5be.fsf@just-testing.permabit.com> <87375r7f0g.fsf@users.sourceforge.net> <9f1e7a1f-bfc0-43a4-9acb-cf69b85587be@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1509989172 26737 195.159.176.226 (6 Nov 2017 17:26:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 6 Nov 2017 17:26:12 +0000 (UTC) Cc: Philipp Stephani , 29165@debbugs.gnu.org, Noam Postavsky To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 06 18:26:06 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 1eBl9x-0006dt-OJ for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Nov 2017 18:26:05 +0100 Original-Received: from localhost ([::1]:49422 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eBlA3-0001Bu-HF for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Nov 2017 12:26:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43108) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eBl9x-0001Be-P3 for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2017 12:26:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eBl9u-0000Gc-UY for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2017 12:26:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45773) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eBl9u-0000GR-OM for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2017 12:26:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eBl9u-0004EE-Ex for bug-gnu-emacs@gnu.org; Mon, 06 Nov 2017 12:26: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 17:26: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.150998913416216 (code B ref 29165); Mon, 06 Nov 2017 17:26:02 +0000 Original-Received: (at 29165) by debbugs.gnu.org; 6 Nov 2017 17:25:34 +0000 Original-Received: from localhost ([127.0.0.1]:54454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBl9R-0004DU-Rv for submit@debbugs.gnu.org; Mon, 06 Nov 2017 12:25:34 -0500 Original-Received: from mail-qt0-f182.google.com ([209.85.216.182]:49290) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eBl9P-0004DH-Qc for 29165@debbugs.gnu.org; Mon, 06 Nov 2017 12:25:32 -0500 Original-Received: by mail-qt0-f182.google.com with SMTP id k31so11872454qta.6 for <29165@debbugs.gnu.org>; Mon, 06 Nov 2017 09:25:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=permabit.com; s=google; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KqQc5cGe8WvJhSHeRllt3iXDO0My+ySu8pcdxYRFVmU=; b=cyHOHv5ZkBID/CItq4wBrl9xUr/ksgNloZIj3+QzW55qHVUTuB9ldvj3sVaoRlmG8b BsYcwi0XCp7hHIgqqb0wFoLxPpbr+sHknwZpfyJkfvencLJ1HNQJJu7xz3/3Iw+Zuc8R TAuF1bRf6onVG8yKLUyCaPcK/xN4TYK8d0Qd0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KqQc5cGe8WvJhSHeRllt3iXDO0My+ySu8pcdxYRFVmU=; b=E3Z+9mnfp9FyvU0Wo1o/pijxi/dDGox1r0Twf+1+FabVXOYNhKlfyERjT9CrtxnN1m wvZcqRKC2/SRHHyOtTrrrb3ZUZDP5tRwGd4bm22zUV69tfq3N/rDFPo/syEQsp1CAvFV rcRB8t4JZofNbuG9+ivyoFrh5OWCQGOiaeJNw0O+QdmN1vaZ1dZ6f2bOebBZI+ufQQv+ 3/yQzs+QC1WyEPYSFmXIb1FDpr8w/YO1Av7MXpi5Ji/9e+dfWDL8qXmYg1J6yl/R0qXv 0d0PXUT6y5I43EYgeH8bXvKWne4FHkQj9FXyoHPslqVAgfn+Ez8epQZPumLVK6RafaeA ZUDw== X-Gm-Message-State: AMCzsaWOr4vxZnvOmaUSuI2zJACLnmAVRsdJybN+Eox68FXqt1a1kTJ6 IHXhPO34/XO8wyOCTyHQlyEdaw== X-Google-Smtp-Source: ABhQp+T8B20H65iE6fw+cP2ITpfWGTcW+Wxic7zEjncB2MZVp2W3UfDL6iwrJ0kFWmnw1jbMv722bA== X-Received: by 10.200.46.114 with SMTP id s47mr23591359qta.165.1509989126445; Mon, 06 Nov 2017 09:25:26 -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 z13sm8968565qtb.97.2017.11.06.09.25.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 06 Nov 2017 09:25:25 -0800 (PST) X-Priority: 3 In-Reply-To: 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:139511 Archived-At: On Nov 6, 2017, at 09:40, Drew Adams wrote: >>>> 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. 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. Ken=