From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Barzilay Newsgroups: gmane.emacs.devel Subject: Re: proposal to make null string handling more emacs-y Date: Sat, 28 Apr 2012 17:56:22 -0400 Message-ID: <20380.26502.202440.851555@winooski.ccs.neu.edu> References: <83d36wfcf1.fsf@gnu.org> <834ns7g9r8.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 1335650195 29887 80.91.229.3 (28 Apr 2012 21:56:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 28 Apr 2012 21:56:35 +0000 (UTC) Cc: emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 28 23:56:33 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 1SOFd3-00049P-Eu for ged-emacs-devel@m.gmane.org; Sat, 28 Apr 2012 23:56:33 +0200 Original-Received: from localhost ([::1]:53820 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SOFd2-0005pj-NR for ged-emacs-devel@m.gmane.org; Sat, 28 Apr 2012 17:56:32 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59209) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SOFd0-0005pa-CI for emacs-devel@gnu.org; Sat, 28 Apr 2012 17:56:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SOFcy-0007HN-F4 for emacs-devel@gnu.org; Sat, 28 Apr 2012 17:56:29 -0400 Original-Received: from winooski.ccs.neu.edu ([129.10.115.117]:38828) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SOFcv-0007Gn-GP; Sat, 28 Apr 2012 17:56:25 -0400 Original-Received: from winooski.ccs.neu.edu (localhost.localdomain [127.0.0.1]) by winooski.ccs.neu.edu (8.14.4/8.14.4) with ESMTP id q3SLuMx9029041; Sat, 28 Apr 2012 17:56:22 -0400 Original-Received: (from eli@localhost) by winooski.ccs.neu.edu (8.14.4/8.14.4/Submit) id q3SLuMnq029037; Sat, 28 Apr 2012 17:56:22 -0400 In-Reply-To: X-Mailer: VM 8.2.0a under 23.2.1 (x86_64-redhat-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 129.10.115.117 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:150129 Archived-At: Four hours ago, Richard Stallman wrote: > As a (semi-fake) "Schemer", I can say that it's perfectly fine in > practice too. It catches real errors. In analogy to what you wrote a > few seconds later -- it catches errors that would otherwise get > papered over. > > The benefit of making () and false the same in Lisp is NOT a matter > of suppressing errors. Sure it is. (null? (< 1 2)) makes no semantic sense, and you get an error. In other lisps, (null (< 1 2)) makes no sense but instead of an error you get a convention of preferring `not'. The error that Scheme throws is suppressed, but using `null' like that is likely to be an error. (BTW, Scheme itself is doing the same when it treats any non-#f value as true. CLers would also argue that Scheme is also doing it when it treats identifiers in function positions the same as elsewhere.) > The benefit is that we can simplify programs by knowing that () and > false are the same. Right, and you get more of these benefits if it's also the same as "" and as 0, and there are additional benefits in the same direction: allow using `nil' as a function (that returns `nil' when called), allow adding numbers, strings, lists, etc with implicit coercions, maybe allow using numbers and lists as functions (as in arc), and allow referring to undefined variables and calling undefined functions. Each of these simplifies (and shortens) existing code, since they each encapsulate common code pattern. But each of these suppresses more bugs since more defective code runs to completion, returning bogus results instead of throwing an error. (I'm talking about defective in the sense of diverging from what the code should do, not in a technical execution sense where they're no longer bugs.) Note in particular that all of these are directly contributing to Steve's proposal: they lead to less frustraing errors, since more code will run without exceptions, implicitly doing something that likely should be done in today's elisp. Note also his reference to running code in a browser, where JS is a language that is very intentionally doing its best to continue running, with modern browsers going farther by not even showing most people errors. Arguing that some of these things are better or worse is wrong. It doesn't make sense to reject unifying "" and `nil' on one hand and reject separating false and '() on the other -- *unless* it's clear that it's a subjective decision. They are very clearly tradeoffs of convenience vs robustness. So the argument is not "scheme is wrong to distinguish false from nil, elisp is right to distinguish the empty string from nil". Instead, it should be an argument about the decision that most elispers do, and finding the right place on the line. > Equating () and "" might perhaps give some benefit of simplifying > programs. You could try looking for places where you could take > advantage of that, to see how much convenience it gives. But this > is a different matter from avoiding errors. (Avoiding errors is what started this thread...) > I tend to think the benefit won't be big, but you can try to show > I'm wrong. (I'm making a meta point about the argument, I don't have any preference for either side.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life!