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 08:27:43 -0800 (PST) Message-ID: References: <20151123193138.GG2004@acm.fritz.box> <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> 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 1448469001 26828 80.91.229.3 (25 Nov 2015 16:30:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Nov 2015 16:30:01 +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 17:29:44 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 1a1cwn-0007Sp-DN for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Nov 2015 17:29:33 +0100 Original-Received: from localhost ([::1]:46307 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1cwo-00009p-Ug for geb-bug-gnu-emacs@m.gmane.org; Wed, 25 Nov 2015 11:29:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56836) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1cwL-00080d-JO for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2015 11:29:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a1cwI-0000yn-AK for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2015 11:29:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35017) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a1cwI-0000yJ-58 for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2015 11:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1a1cwH-0001oN-Pw for bug-gnu-emacs@gnu.org; Wed, 25 Nov 2015 11: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 16: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.14484688906889 (code B ref 20241); Wed, 25 Nov 2015 16:29:01 +0000 Original-Received: (at 20241) by debbugs.gnu.org; 25 Nov 2015 16:28:10 +0000 Original-Received: from localhost ([127.0.0.1]:52958 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1cvR-0001n2-27 for submit@debbugs.gnu.org; Wed, 25 Nov 2015 11:28:09 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:20705) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1a1cv6-0001mI-FT for 20241@debbugs.gnu.org; Wed, 25 Nov 2015 11:28:07 -0500 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tAPGRkVn013640 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Nov 2015 16:27:46 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id tAPGRj9j025593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Nov 2015 16:27:45 GMT Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id tAPGRiiu006538; Wed, 25 Nov 2015 16:27:45 GMT In-Reply-To: <20151125154030.GF2007@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: aserv0021.oracle.com [141.146.126.233] 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:109238 Archived-At: > > If you cannot now analyze the code properly to determine TRT, or > > contact the author to make that determination, then do the obvious > > (IMO): Assign a `nil' value explicitly where it is now assigned > > implicitly. >=20 > That would be the worst thing: it would leave the code possibly failing > exactly the way it did, but remove the evidence (which can be > mechanically found). It would leave the code behaving exactly as it did before. AND it would add information to developers that there is possibly an error here - right here, in this sexp here. AND it would say clearly what that possible error is. That doesn't "remove the evidence". It puts a big sign around the evidence saying "**EVIDENCE** - Check this code to see whether it should really should assign a nil value. But if you can DTRT now - analyze the code sufficiently and fix it properly or contact the author for an opinion - then that's the thing to do. Or if you just leave the code as is, but ensure that a runtime error is raised, that is also TRT. It takes care of THIS bug, but it does not fix that bug (indicated by the error occurrence). That's fine. When the error is raised someone can then work on fixing that bug. They can take the time to analyze and fix it properly. And they can ensure, while they are working on it, that the code at least runs as it did before - by doing what I suggested above: explicitly assign `nil' and add a comment. =20 > > AND flag that amended code with a comment saying what you've done, > > and that you don't currently know whether (a) there is a bug here > > or (b) `nil' is really what is needed. >=20 > Comments are less good than error messages from the byte compiler! I disagree. Each can be helpful in its own way. In this case, we have already located the potential problem, and the (right) message to developers about it is that THERE IS an assignment of `nil' and IT MIGHT BE PROBLEMATIC. The source code is a good place to convey that message, right next to the suspect assignment. > > IOW: (1) At least just ensure that the code does the same thing > > that it does now, but respects the intended meaning of `setq'. > > (2) If you have to punt the careful analysis for later or for > > someone else, then add a comment to that effect. >=20 > > > Maybe having the byte compiler error out in this situation > > > isn't such a brilliant idea after all. >=20 > > IMO, the bug should be fixed to raise an _error at runtime_, > > for both interpreted and byte-compiled code. >=20 > I've just tried it out. The byte compiler generates an error message, > but the .elc is written anyway. No runtime error happens from such > compiled code. But running it interpreted would signal an error. And who will run it interpreted? THIS is worse than nothing, IMO. What counts is the runtime behavior. And that counts for both source code and byte-compiled code. > > Whatever else the byte-compiler might do is less important, as > > long as it produces code that is comparable - e.g., code that > > will also raise an _error at runtime_. >=20 > It currently doesn't do that. I'm not convinced it should, either. What would it take to convince you? What is the purpose of byte-compilation, in terms of the resulting code? Is it to change the behavior in ways other than optimization? I don't think so. The byte-compiler is not just some QA tool to check whether i's are dotted and t's are crossed. It produces _code_ that is _run_, and that runtime behavior should reflect the programmer's intention. And that intention is expressed in the source-code language (which can include declarations to a compiler, but that's beside the point here). > > It's OK for a byte-compiler to be smart, but not smarter than > > the actual source code ;-). It should pretty much try to > > produce code that does the same thing, but hopefully usually > > does it quicker. >=20 > Why is this topic suddenly seeming complicated? :-( I don't think it's complicated. `setq' should raise an error when it is passed an odd number of arguments. _That's all._ The error should be raised when `setq' is invoked, obviously. Anything else we might decide to do is extra communication to programmers _about_ the code. But the code itself should DTRT. Assigning `nil' for a missing value arg is not the right thing; raising an error is the right thing. If you want to leave the problematic code as is, but ensure that a runtime error is raised, that's fine. It is the right thing. But IF you decide to try to fix the problematic code now, and IF you feel you are unsure about the fix, THEN the best thing to do is to keep the behavior as it was (assign `nil'), but make that behavior explicit and question it with a comment. I would rather opt for just leaving the code as it is - erroneous, and let it raise a runtime error. But then we will be in the same boat for fixing that error: analyze or contact the author, etc.