From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#20241: 25.0.50; `setq' with only one argument Date: Wed, 25 Nov 2015 10:28:11 -0800 (PST) Message-ID: <5c5c14de-444e-4847-b91a-e7dff29b3f58@default> References: <20151124180452.GB1840@acm.fritz.box> <20151124210956.GC1840@acm.fritz.box> <20151125094155.GB2007@acm.fritz.box> <20151125110755.GC2007@acm.fritz.box> <20151125154030.GF2007@acm.fritz.box> <20151125172211.GH2007@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1448476167 19228 80.91.229.3 (25 Nov 2015 18:29:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Nov 2015 18:29:27 +0000 (UTC) Cc: John Wiegley , 20241@debbugs.gnu.org, Artur Malabarba To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Nov 25 19:29:12 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1a1eoW-0007QC-5A for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Nov 2015 19:29:08 +0100 Original-Received: from localhost ([::1]:47116 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1eoX-0005rq-Pk for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Nov 2015 13:29:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40960) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1eoU-0005rj-05 for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2015 13:29:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1eoP-0001ub-To for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2015 13:29:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35154) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1eoP-0001uS-Qq for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2015 13:29:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a1eoP-0004u5-JC for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2015 13:29:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Nov 2015 18:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20241 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20241-submit@debbugs.gnu.org id=B20241.144847610018799 (code B ref 20241); Wed, 25 Nov 2015 18:29:01 +0000 Original-Received: (at 20241) by debbugs.gnu.org; 25 Nov 2015 18:28:20 +0000 Original-Received: from localhost ([127.0.0.1]:53095 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1enk-0004t9-0E for submit@debbugs.gnu.org; Wed, 25 Nov 2015 13:28:20 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:26719) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1eni-0004t0-1h for 20241@debbugs.gnu.org; Wed, 25 Nov 2015 13:28:18 -0500 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAPISDJj010249 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Nov 2015 18:28:13 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id tAPISCpE028328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Nov 2015 18:28:13 GMT Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tAPISCT9010221; Wed, 25 Nov 2015 18:28:12 GMT In-Reply-To: <20151125172211.GH2007@acm.fritz.box> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:109249 Archived-At: > 1. Interpreter: > (a) Current behviour: silently insert a nil into the `setq'. > (b) Throw an error (current new behaviour in emacs-25). > (c) Issue a warning, but continue otherwise with (a). 1b is what I prefer. > 2. Compiler: > (a) Silently compile code which slips in a nil (current behaviour). > (b) Issue a warning, but compile in the nil. > (c) Issue an error, but compile in the nil. (current new behaviour > in emacs-25.) > (d) Issue an error, and abort the compilation: > (i) immediately. > (ii) at the end of the source file. > (e) Issue an error, and generate code to: > (i) issue a warning, but carry on with the nil. > (ii) throw an error. Code that applies `setq' to an odd number of args is erroneous syntactically. The compiler can point out that syntax error. And it need not (and should not) abort the compilation just because it reports that syntax error - it can continue to report other problems. Or if by "abort" you mean just not produce compiled output (but continue to analyze the code and report as many problems as possible), I don't think that is necessary (or good) either, in this case (provided that the resulting code raises a runtime error.) > You seem to favour 1(b) and, I think, 2(d)(ii) or 2(e)(ii). > I favour 1(b) and probably 2(c), possibly 2(e)(i). My preference for the compiler is to (a) let you know there are syntax problems, and where they are, and (b) generate code that acts the same as the interpreted code: in this case, raise a runtime error. > To me, these possibilities are complicated. It's not a > technical problem, it's a social problem: who's going to be > notified of the problem and when. I would far rather > maintainers were hassled than users. As long as the code is erroneous, users should get an error from it. If you can fix the code then they won't get an error. If you cannot fix it now, then they should get an error. If it's important enough that they not get the error then it's important enough that the code should be fixed (e.g., before the release). Anyway, I'm no doubt repeating myself now. At least you know now what I prefer for the behavior, including for the compiler. FWIW. And thanks for working on this.