From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: proposal to make null string handling more emacs-y Date: Fri, 27 Apr 2012 14:24:59 -0700 Message-ID: <93BCB9FDF9D2443988F559AD4BEC4DBD@us.oracle.com> References: <83d36wfcf1.fsf@gnu.org> <834ns7g9r8.fsf@gnu.org> <83zk9xheam.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1335561928 9447 80.91.229.3 (27 Apr 2012 21:25:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 27 Apr 2012 21:25:28 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: "'Steve Yegge'" , "'Eli Zaretskii'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 27 23:25:25 2012 Return-path: Envelope-to: ged-emacs-devel@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 1SNsfM-0006sh-H8 for ged-emacs-devel@m.gmane.org; Fri, 27 Apr 2012 23:25:24 +0200 Original-Received: from localhost ([::1]:42796 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNsfL-00034n-TK for ged-emacs-devel@m.gmane.org; Fri, 27 Apr 2012 17:25:23 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:38081) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNsfI-00034e-2a for emacs-devel@gnu.org; Fri, 27 Apr 2012 17:25:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SNsfF-0001Z3-Vv for emacs-devel@gnu.org; Fri, 27 Apr 2012 17:25:19 -0400 Original-Received: from acsinet15.oracle.com ([141.146.126.227]:19458) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNsfB-0001WY-Sa; Fri, 27 Apr 2012 17:25:14 -0400 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3RLP6QQ011559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 Apr 2012 21:25:07 GMT Original-Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q3RLP5jA026441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Apr 2012 21:25:05 GMT Original-Received: from abhmt102.oracle.com (abhmt102.oracle.com [141.146.116.54]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q3RLP4PY008038; Fri, 27 Apr 2012 16:25:04 -0500 Original-Received: from dradamslap1 (/10.159.177.52) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 27 Apr 2012 14:25:04 -0700 X-Mailer: Microsoft Office Outlook 11 In-reply-to: Thread-Index: Ac0kqMKBwpZ9eHWURPWZTTmFmqUU7wAAJj6A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Source-IP: ucsinet21.oracle.com [156.151.31.93] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 141.146.126.227 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:150096 Archived-At: > I've decided that throwing errors on nil strings -- however > good the intentions may have been -- is doing more harm than good. ... > I'm arguing that for a very specific corner of the type system, > we merge two separate meanings of nil. I'm arguing that the > empty string as it is used today is, for all intents, just > another nil. So it should not signal an error if they are > treated the same. Just because "" and () are similar in some ways does not mean that they should be treated as identical in general - any more than [] and () should be. "For all intents, just another nil" can apply to a lot of things, including 0 for whole numbers. Should we conclude also that throwing errors on nil numbers, like "nil strings", does more harm than good? No, you didn't make so general an argument - good. You limited it to "all the core string-manipulation functions" (not very clear to me), and even more specifically to "the smallest set of [core?] functions that may originate the infamous `wrong-type-argument (stringp, nil)' error". But that still quite general appeal wrt string type errors ("Throwing an error on a nil string is a radical departure from the core philosophy.") was countered by pointing out that sometimes it is TRT to raise such an error. And you yourself said in the same breath that "Emacs libraries should already do nil-checking on string arguments." Surely they do, and in some cases they raise an error as a consequence, and in some cases the only possible or the most appropriate error is the one being decried. As long as we discuss this at such a general level your argument will not go far, I'm afraid. So you say even more narrowly that there is a well-defined class of cases - a "corner" where you feel that "" and () should be equated and raising an error is wrong. I fear that even this more constrained hand-waving is still unlikely to cut the mustard, but if you nail it down clearly then maybe you can progress with it. If you are convinced that your argument is truly more general than what can be dealt with case by case, and you can accurately identify the "very specific corner of the type system" that merits such a change, then, by all means, identify it rigorously and give supporting arguments. IOW, be specific about your very specific corner. Specify the problem and its boundaries. Barring that, I'd add my voice to the advice already given by others: handle any particular functions that you feel ought to treat "" and () the same, but do not yet do so, on a case-by-case basis. Start with a specific function where you think it is bad design to distinguish "" from () and to raise an error when () is encountered but "" was expected (i.e., acceptable). For that function, point to a specific problem - e.g. a startup problem, since you refer to that. IOW2, give specific arguments for each such function as to why it should equate "" and (). IOW3, identify the specific problems you've run into - file a bug, for instance. You are much more likely to have others see your light if you are specific and clear. In fact, if you had started with a specific bug report, it's quite possible that others would themselves have made the same leap to your "corner", assuming it is well-defined. Finally, you say that the "real reason" for your quest is that if such an error is raised at startup then a newbie's goose is nuked. For that, I'm afraid, the replique given already is the right one: recipe please. It sounds like you or someone you know has stumbled on a bug that needs fixing. And that, I think, is the place to start. It is, after all, the real problem behind your real reason. FWIW, I am sympathetic to the problem you describe. I even filed a (non-specific, no-recipe, not-very-useful) bug report a while back that could perhaps be a poster child for the "worse" scenario you cite: "If Emacs can't start up, or (worse) it gets into one of those horrid scenarios where some hook is throwing an error on almost every command and preventing the user from doing anything useful, then you're no longer in Emacs. You're in brokenville. All the advantages and pleasure of Emacs as a dev environment have vanished." http://debbugs.gnu.org/cgi/bugreport.cgi?bug=11105 And yes, debugging that one (in particular, but perhaps it is not really so particular) is not so simple. But the good news is that I see this particular behavior _only_ in Emacs 24, which is not yet released. So your argument about developers vs users, even in the narrow sense in which it might sometimes be appropriate, does not really apply here. The better news will be when the bug can be found and fixed. But so far at least I'm not convinced that your proposal is the right way to deal with this case. I'd sooner see it found and fixed than finessed.