From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: proposal to make null string handling more emacs-y Date: Fri, 27 Apr 2012 22:02:10 -0400 Message-ID: References: <83d36wfcf1.fsf@gnu.org> <834ns7g9r8.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1335578546 12930 80.91.229.3 (28 Apr 2012 02:02:26 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 28 Apr 2012 02:02:26 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Steve Yegge Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 28 04:02: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 1SNwzR-0002Ka-9U for ged-emacs-devel@m.gmane.org; Sat, 28 Apr 2012 04:02:25 +0200 Original-Received: from localhost ([::1]:36990 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNwzQ-0000mH-KN for ged-emacs-devel@m.gmane.org; Fri, 27 Apr 2012 22:02:24 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43239) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNwzN-0000lv-Jj for emacs-devel@gnu.org; Fri, 27 Apr 2012 22:02:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SNwzL-0008Ic-SL for emacs-devel@gnu.org; Fri, 27 Apr 2012 22:02:21 -0400 Original-Received: from ironport-out.teksavvy.com ([206.248.143.162]:24093) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SNwzJ-0008H1-8s; Fri, 27 Apr 2012 22:02:17 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApYIACxOgk9soXnu/2dsb2JhbABDuCMDgQyBCIIJAQEEAVYjBQsLNBIUGA0kiBwFtjKLYYR5BKRFgV2DAw X-IronPort-AV: E=Sophos;i="4.75,391,1330923600"; d="scan'208";a="177276972" Original-Received: from 108-161-121-238.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([108.161.121.238]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 27 Apr 2012 22:02:12 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 949DEAE233; Fri, 27 Apr 2012 22:02:10 -0400 (EDT) In-Reply-To: (Steve Yegge's message of "Thu, 26 Apr 2012 21:17:36 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.143.162 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:150102 Archived-At: > compile time. When you're running the byte compiler or the unit tests, you > want it to fail loudly and early. 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. Most of the time throwing an `error' doesn't prevent the user from getting his job done. E.g. it doesn't "crash" Emacs. And while the user may not be able to debug it himself, he is able to get a backtrace and send it to us, whereas with a more permissive semantics, you don't get anything, so fixing the problem will require more interactions with the user. IOW, I think the problem is when an error makes Emacs unusable, and we should focus on this (which is typically an issue that's not dependent on the kind of error signaled, but the context where it's signaled). > With that in mind, I'm really wondering what the big fear is here. I have no big fear about your proposal. I expect it won't make much difference. > I don't see any of these creating world-ending bugs, contrary to > predictions. I don't expect any change you suggested would bring a significant number of bugs. The only downside I mention is that it might hide some bugs (which would have existed regardless of that change) and make them more difficult to track down and fix. Of course, maybe it will also fix some bugs. And maybe it will also allow us to simplify some Lisp code. I general I like the idea of treating lists and vectors uniformly, and strings are one particular kind of vector. But Emacs is a conservative system, so changes have to go slow. Send us a patch that covers the most obviously beneficial cases (ideally with some code cleanup made possible by the new semantics), Stefan