From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp's future Date: Thu, 18 Sep 2014 05:17:06 +0200 Message-ID: <871tr9ty6l.fsf@fencepost.gnu.org> References: <87wq97i78i.fsf@earlgrey.lan> <87sijqxzr2.fsf@newcastle.ac.uk> <878uliwajb.fsf@taylan.uni.cx> <87lhpitg6t.fsf@fencepost.gnu.org> <87wq92uhwh.fsf@taylan.uni.cx> <541A0E71.6040703@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1411010295 22518 80.91.229.3 (18 Sep 2014 03:18:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Sep 2014 03:18:15 +0000 (UTC) Cc: Taylan Ulrich Bayirli/Kammer , emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 18 05:18:10 2014 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 1XUSET-0005hD-I1 for ged-emacs-devel@m.gmane.org; Thu, 18 Sep 2014 05:18:09 +0200 Original-Received: from localhost ([::1]:48293 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUSET-0008BA-1q for ged-emacs-devel@m.gmane.org; Wed, 17 Sep 2014 23:18:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47638) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUSED-0008Ar-Ng for emacs-devel@gnu.org; Wed, 17 Sep 2014 23:17:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XUSEC-0006WL-5k for emacs-devel@gnu.org; Wed, 17 Sep 2014 23:17:53 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37735) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUSEC-0006VX-2F for emacs-devel@gnu.org; Wed, 17 Sep 2014 23:17:52 -0400 Original-Received: from localhost ([127.0.0.1]:44909 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XUSE5-0003ux-Uh; Wed, 17 Sep 2014 23:17:46 -0400 Original-Received: by lola (Postfix, from userid 1000) id CDEF3E11DE; Thu, 18 Sep 2014 05:17:06 +0200 (CEST) In-Reply-To: <541A0E71.6040703@dancol.org> (Daniel Colascione's message of "Wed, 17 Sep 2014 15:42:57 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:174478 Archived-At: Daniel Colascione writes: > On 09/17/2014 01:11 PM, Taylan Ulrich Bayirli/Kammer wrote: >> Actually, this is just a special-case of the first point, regarding the >> applicable data type (libguile procedures) being handled in a uniform >> way without extra overhead in the case it "comes from the other >> language." >>=20 >>>> - The handling of nil vs. Scheme #f and '() is admittedly a wart, but >>>> will probably remain hidden, not causing issues in code you write. >>> >>> I have problems seeing how it can remain hidden. >>=20 >> Please mention any concrete problematic cases you can think up. > > Imagine the round trip a value might take: #f in Scheme to nil in elisp > to something back in Scheme. It doesn't. See . I quote: However, in Elisp, '(), #f, and nil are all equal (though not eq). (defvar f (make-scheme-false)) (defvar eol (make-scheme-null)) (eq f eol) =E2=87=92 nil (eq nil eol) =E2=87=92 nil (eq nil f) =E2=87=92 nil (equal f eol) =E2=87=92 t (equal nil eol) =E2=87=92 t (equal nil f) =E2=87=92 t > If you alias #f, (), and nil together from an elisp perspective, then > when you need to differentiate these values, you can't, because you've > just thrown away the information you'd need to do that. You can't make > the object's true identity a hidden property of the value either, > because that breaks perfectly valid code like this: > > (defun identity-x (x) (if (eq x nil) nil x)) (eq x nil) is just something you are not expected to do if a list or condition may come from a Scheme function. Of course, that includes using x for eq-based hashing. The GUILE manual (in the above-mentioned section) states with audacity Fortunately, using not and null? is in good style, so all well-written standard Scheme programs are correct, in Guile Scheme. Of course, that glosses over the fact that the end of a list may well be implicitly checked for by using sentinels and other quite legitimate programming practices. For example, two proper lists generally have a common tail, even if that tail is only '(), and finding that tail is done by trimming the longer list to the size of the shorter one and then cdr-ing the remaining lists in synch until arriving at a matching value. Using "equal" for that comparison is not an option, and using "eq" is no longer guaranteed to terminate without error. The solution is to declare the algorithm not well-written. Cynicism aside, it will be advisable not to venture into Scheme too much in order to avoid having the Scheme end-of-list and the Scheme #f turn up at all. --=20 David Kastrup