From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: proposal to make null string handling more emacs-y Date: Fri, 27 Apr 2012 09:36:17 +0300 Message-ID: <83zk9xheam.fsf@gnu.org> References: <83d36wfcf1.fsf@gnu.org> <834ns7g9r8.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1335508588 17032 80.91.229.3 (27 Apr 2012 06:36:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 27 Apr 2012 06:36:28 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Steve Yegge Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 27 08:36:27 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 1SNen0-00070G-Ih for ged-emacs-devel@m.gmane.org; Fri, 27 Apr 2012 08:36:22 +0200 Original-Received: from localhost ([::1]:32968 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNen0-0000FL-01 for ged-emacs-devel@m.gmane.org; Fri, 27 Apr 2012 02:36:22 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNemw-0000ES-E4 for emacs-devel@gnu.org; Fri, 27 Apr 2012 02:36:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SNemu-0001mx-R2 for emacs-devel@gnu.org; Fri, 27 Apr 2012 02:36:17 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:61219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNemu-0001mn-JI for emacs-devel@gnu.org; Fri, 27 Apr 2012 02:36:16 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M3400K00KW6HW00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Fri, 27 Apr 2012 09:36:14 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.229.249.186]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M3400KB9L0D9E80@a-mtaout22.012.net.il>; Fri, 27 Apr 2012 09:36:14 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 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:150083 Archived-At: > Date: Thu, 26 Apr 2012 21:17:36 -0700 > From: Steve Yegge > Cc: Eli Zaretskii , emacs-devel@gnu.org > > But type errors are for *developers*. They are supposed to happen at > compile time. When you're running the byte compiler or the unit tests, you > want it to fail loudly and early. This is Lisp, not C++ or even Java. Some Lisp code is never compiled at all. A notable example is the code you put in .emacs. > But when you ship the software, and it's in the hands of end-users > who may not be able to debug it, then unless it's running a nuclear > reactor or an airplane, you want the software to be robust. Your > browser shouldn't crash because of a misbehaved site; your web page > shouldn't fail to load because of a misbehaved widget; your CAD > program shouldn't stop functioning because of a misbehaved polygon. > Yes, the resulting bug will be annoying, but it's far less annoying > than having your work interrupted altogether. I don't think you can have an interpreted language without runtime exceptions. In Lisp, if you want robust programs, you need to catch exceptions and do something reasonable. Asking to avoid exceptions altogether is IMO impractical. > Similarly, I see a whole bunch of file-name manipulation functions that > accept the empty string as an argument. But the empty string has no > semantic meaning whatsoever as a valid filename. Without any semantic > meaning, it's arguably a bug to pass one in. The usual Emacs semantics for an empty file name is that it stands for the current directory.