From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: guile and elisp Date: Sat, 27 Mar 2010 14:01:59 -0400 Message-ID: <20100327180158.GC9481@fibril.netris.org> References: <20100327130750.GA9026@fibril.netris.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1269712945 10225 80.91.229.12 (27 Mar 2010 18:02:25 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 27 Mar 2010 18:02:25 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Mar 27 19:02:21 2010 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NvaKx-0001D9-Uv for guile-devel@m.gmane.org; Sat, 27 Mar 2010 19:02:20 +0100 Original-Received: from localhost ([127.0.0.1]:50492 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NvaKs-0000qP-RX for guile-devel@m.gmane.org; Sat, 27 Mar 2010 14:02:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NvaKp-0000pl-Nm for guile-devel@gnu.org; Sat, 27 Mar 2010 14:02:11 -0400 Original-Received: from [140.186.70.92] (port=43405 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NvaKn-0000oO-WE for guile-devel@gnu.org; Sat, 27 Mar 2010 14:02:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NvaKm-0004Ni-8C for guile-devel@gnu.org; Sat, 27 Mar 2010 14:02:09 -0400 Original-Received: from world.peace.net ([216.204.32.208]:48843) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NvaKm-0004NX-2I for guile-devel@gnu.org; Sat, 27 Mar 2010 14:02:08 -0400 Original-Received: from localhost ([127.0.0.1] helo=fibril.netris.org ident=hope1) by world.peace.net with esmtp (Exim 4.69) (envelope-from ) id 1NvaKe-0001XY-Vj; Sat, 27 Mar 2010 14:02:01 -0400 Content-Disposition: inline In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:10094 Archived-At: (BTW, I'm deliberately writing "lisp" instead of "elisp" because these discussions should be relevant to any lisp dialect that uses nil for both false and eol, and in the future guile might support other lisps). On Sat, Mar 27, 2010 at 05:54:24PM +0100, Andy Wingo wrote: > I'm not sure (I keep saying "not sure", and I'm really not :) that > *value* or *identity* is the way to solve this problem. To me the > question is more of *property* -- is this value false, is it equal? to > another, is it a boolean, etc. Well, if we can assume that all non-lisp code in the guile system will robustly handle nil by using the appropriate predicates, then yes, that's a fine solution with clear semantics. I just don't think we can safely assume that. Someday there may be significant libraries and other complex software developed elsewhere being used in guile-emacs. Most code outside of the lisp world has never had to cope with an ambiguous "maybe boolean false or maybe the empty list" value. When that code meets the lisp world, I guarantee you'll start seeing obscure bugs crop up. The system as a whole will not be as robust as it could be. A lot of code outside of lisp uses equality to test boolean values. If nil is distinct from #f, then that code will fail. A lot of code assumes that if a value is boolean, then it cannot be a list, and vice versa. Some code looks up booleans and/or lists in hash tables or other structures. That code won't deal gracefully with list structures containing nil. Some object-oriented languages may overload an operation depending on whether a parameter is a boolean or a list. I don't see how such code can deal with nil gracefully without being significantly rewritten. Using your proposed intransitive equality predicates would handle many of the common cases properly, but not all of them. I see no way to handle these kinds of problems robustly without gradually deprecating nil. My proposal allows instances of nil to be incrementally "annotated" by changing them to #f or '(). Lisp code treats all three values the same, so from lisp's point of view these annotations are harmless and effectively no-ops. But each annotation has the potential to prevent some obscure nil-related bugs from breaking non-lisp code which wasn't designed to handle nil. These annotations could be done in response to the discovery of a nil-related bug, or they could be done preemptively to reduce the probability of such bugs before they occur. They could be done either in the lisp sources, or elsewhere using my proposed "canonicalize-*" procedures, perhaps where values are passed from lisp to non-lisp code, or upon entry to code which is known not to handle nil gracefully. So, I guess I should have been more broad when I said that I want "clear semantics". More than that, I want to be able to robustly mix lisp code with other code that was never designed to interface well with lisp, with a minimum of obscure bugs cropping up. The gradual deprecation of nil (or at least the option of eventually doing so) is the only path I see to toward that end. Regards, Mark