From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.bugs Subject: bug#24913: 25.1.50; Emacs accepts undocumented and confusing combinations of &optional and &rest in argument lists Date: Sun, 20 Nov 2016 12:41:02 +0000 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bb04050bb13030541bada0b X-Trace: blaine.gmane.org 1479645734 30173 195.159.176.226 (20 Nov 2016 12:42:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 20 Nov 2016 12:42:14 +0000 (UTC) Cc: 24913@debbugs.gnu.org To: Gemini Lasswell Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 20 13:42:10 2016 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 1c8RRi-0007B9-9K for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Nov 2016 13:42:10 +0100 Original-Received: from localhost ([::1]:44635 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8RRl-0006Yc-MW for geb-bug-gnu-emacs@m.gmane.org; Sun, 20 Nov 2016 07:42:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43134) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8RRf-0006Y3-3R for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2016 07:42:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c8RRa-0003F2-5c for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2016 07:42:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48509) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c8RRa-0003Em-0b for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2016 07:42:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1c8RRZ-0007ok-Qd for bug-gnu-emacs@gnu.org; Sun, 20 Nov 2016 07:42:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 20 Nov 2016 12:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24913 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 24913-submit@debbugs.gnu.org id=B24913.147964568129992 (code B ref 24913); Sun, 20 Nov 2016 12:42:01 +0000 Original-Received: (at 24913) by debbugs.gnu.org; 20 Nov 2016 12:41:21 +0000 Original-Received: from localhost ([127.0.0.1]:35675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c8RQu-0007ng-Ol for submit@debbugs.gnu.org; Sun, 20 Nov 2016 07:41:21 -0500 Original-Received: from mail-wj0-f178.google.com ([209.85.210.178]:36508) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1c8RQs-0007nP-NP for 24913@debbugs.gnu.org; Sun, 20 Nov 2016 07:41:19 -0500 Original-Received: by mail-wj0-f178.google.com with SMTP id qp4so15515643wjc.3 for <24913@debbugs.gnu.org>; Sun, 20 Nov 2016 04:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=koPQ/bO7vczaz7wA2O/0ioKiMnOXqFwkkPuLtXu7oHk=; b=gcE86JBKZoL8Y33BQenjNKNe2/RJDagzuGcylMplfOYSUxvhMfonm0W7HPpwAyL5yr kIY0iQWaEytqfTtzR9sN0Vc6+44vycksn43SmOQMhSQx4KY35KitLLTGed5WvicBE4ec s3hnCiqcVEus4E20XlyFzSMSOt7h7Z4ce557902fHRVtgP3e8t45/2bWbMDTZuHkWpCY itVzICXMwoNXkKuBXDgk+mSWgfbHcJG9NdPy73M7gNjo8uQfXVpprc3CwoEptdXNa437 bxX2lkVZvnLPZzWelcxblS9xFKK+cDr2hyTD7TaubDglKhe8tynobQXtd5cmzrn/kYQj MwcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=koPQ/bO7vczaz7wA2O/0ioKiMnOXqFwkkPuLtXu7oHk=; b=OVoU1zMzSA/P4MK6MnCLqjn/XpY3d4lXCEQYq4htUu5zoa1eXmjRtVAa+zWB0G3u8l 1EfNabngHbGaj0eeU85X+FmLhkN46LcLC7hXFQSLrADd1anTtTAc6MpkCePIKNKfsZEQ jvaKhqh45kHbvNqqvg+3f+YRJvWc/94S3xi2gqYnyGPk2SMA/ELEL0VTVzDTdjS6sVQG IveY3Fer9PRdoJrMNLTmL2keGaf94wjU0NU7942Ojt+oUMZ5SIl6EHh4mMsWwPSVB4Ou qpTyV/uqBOvrvRCdI1yrYrGxmVjryKicXRYIpBFITm11HtyRv9ZVWQkZThqfUD3AAYHI HasQ== X-Gm-Message-State: AKaTC01fnl0EkZM0xBWLlw46woFP/pp4cIOTQUdy2tdmY1dx0kMKLCuV0yJ6wcyGTS8kyZqRH1sATWLnRCELJw== X-Received: by 10.194.95.35 with SMTP id dh3mr6168943wjb.141.1479645672966; Sun, 20 Nov 2016 04:41:12 -0800 (PST) In-Reply-To: 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:125894 Archived-At: --047d7bb04050bb13030541bada0b Content-Type: text/plain; charset=UTF-8 Gemini Lasswell schrieb am So., 20. Nov. 2016 um 07:31 Uhr: > Philipp Stephani writes: > > > A more general solution would be to have the byte compiler try to match > > Edebug specs, and issue a warning or an error if it fails. That would > > help find errors in the invocations of all macros, not just ones with > > argument lists. > > > > I don't understand how this is related. This is only about function > > definitions in the evaluator and the byte compiler. I don't see how > > Edebug could help here. > > Edebug specs describe the expected syntax for the arguments of a macro, > including the macros which define functions, such as lambda, defun, > defmacro etc. If Edebug can't match the actual arguments in a macro > invocation to the Edebug spec for that macro, it will signal an error. > For an example of Edebug catching a misplaced &optional in an argument > list, see bug#24762. > > So part of my suggestion is that since there exists in Emacs a powerful > mechanism for checking macro argument lists, it would be better to use > it if we want to let programmers know that their macro invocations are > incorrect, instead of adding error checking to individual macros on a > case by case basis. > > Another thought going into this suggestion is my observation that it's > not difficult to find bugs in Edebug specs in the Emacs sources right > now. One cause of that could be the Edebug spec documentation, which > could be improved. But I think the primary reason is that a macro with a > broken Edebug spec won't cause an error until someone tries to use > Edebug or Testcover on an invocation of that macro, which maybe isn't > common practice when reviewing changes. But if the byte compiler checked > Edebug specs and signaled errors, then at least those errors in Edebug > specs which can be found statically would be noticed immediately. > Integrating Edebug checks, byte-compiler checks, and evaluator checks sounds like the right thing to do, but also like a huge amount of work that is out of scope for this bug. Please create a new bug if you want that. Note that a generic checker would still need to catch cases such as (funcall (function (lambda (&rest))) ()) that don't involve any macros. --047d7bb04050bb13030541bada0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Gemini= Lasswell <gazally@runbox.com&= gt; schrieb am So., 20. Nov. 2016 um 07:31=C2=A0Uhr:
Philipp Stephani <p.stephani2@gmail.com> wr= ites:

>=C2=A0 A more general solution would be to have the byte compiler try t= o match
>=C2=A0 Edebug specs, and issue a warning or an error if it fails. That = would
>=C2=A0 help find errors in the invocations of all macros, not just ones= with
>=C2=A0 argument lists.
>
> I don't understand how this is related. This is only about functio= n
> definitions in the evaluator and the byte compiler. I don't see ho= w
> Edebug could help here.

Edebug specs describe the expected syntax for the arguments of a macro,
including the macros which define functions, such as lambda, defun,
defmacro etc. If Edebug can't match the actual arguments in a macro
invocation to the Edebug spec for that macro, it will signal an error.
For an example of Edebug catching a misplaced &optional in an argument<= br class=3D"gmail_msg"> list, see bug#24762.

So part of my suggestion is that since there exists in Emacs a powerful
mechanism for checking macro argument lists, it would be better to use
it if we want to let programmers know that their macro invocations are
incorrect, instead of adding error checking to individual macros on a
case by case basis.

Another thought going into this suggestion is my observation that it's<= br class=3D"gmail_msg"> not difficult to find bugs in Edebug specs in the Emacs sources right
now. One cause of that could be the Edebug spec documentation, which
could be improved. But I think the primary reason is that a macro with a broken Edebug spec won't cause an error until someone tries to use
Edebug or Testcover on an invocation of that macro, which maybe isn't common practice when reviewing changes. But if the byte compiler checked Edebug specs and signaled errors, then at least those errors in Edebug
specs which can be found statically would be noticed immediately.

Integrating Edebug checks, = byte-compiler checks, and evaluator checks sounds like the right thing to d= o, but also like a huge amount of work that is out of scope for this bug. P= lease create a new bug if you want that.
Note that a generic chec= ker would still need to catch cases such as
(funcall (function (l= ambda (&rest))) ())
that don't involve any macros.=C2=A0<= /div>
--047d7bb04050bb13030541bada0b--