From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.user Subject: Re: A value for "nothing" Date: Mon, 27 Aug 2018 16:12:21 -0400 Message-ID: <87wosbsh5m.fsf@netris.org> References: <21036238.c6yQEfjfIL@aleksandar-ixtreme-m5740> <87sh30vqmm.fsf@netris.org> <20180827080415.GB10407@tuxteam.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1535400743 15126 195.159.176.226 (27 Aug 2018 20:12:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Aug 2018 20:12:23 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: guile-user@gnu.org To: Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Aug 27 22:12:19 2018 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fuNs2-0003pJ-UV for guile-user@m.gmane.org; Mon, 27 Aug 2018 22:12:19 +0200 Original-Received: from localhost ([::1]:34979 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fuNu9-000293-0C for guile-user@m.gmane.org; Mon, 27 Aug 2018 16:14:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53371) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fuNti-00028y-SB for guile-user@gnu.org; Mon, 27 Aug 2018 16:14:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fuNtd-00051Q-0H for guile-user@gnu.org; Mon, 27 Aug 2018 16:14:02 -0400 Original-Received: from world.peace.net ([64.112.178.59]:47836) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fuNtc-00050H-Ng for guile-user@gnu.org; Mon, 27 Aug 2018 16:13:56 -0400 Original-Received: from mhw by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1fuNta-0005sC-RK; Mon, 27 Aug 2018 16:13:54 -0400 In-Reply-To: <20180827080415.GB10407@tuxteam.de> (tomas's message of "Mon, 27 Aug 2018 10:04:15 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 64.112.178.59 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.org gmane.lisp.guile.user:14789 Archived-At: writes: > On Sun, Aug 26, 2018 at 04:07:13PM -0400, Mark H Weaver wrote: > >> I would also avoid Guile's #nil. That is a very special value, for one >> purpose relating to Elisp compatibility, and ideally it should not be >> used for anything else. > > I must admit that I'm... pretty confused about this very prescriptive > tone. You're right, I should have explained. I'm overburdened at the moment. For one thing, HiPhish has already indicated that his library will support both Guile and Racket, so I conclude that he's at least somewhat interested in portability to other Scheme implementations. If he would like people to be able to write code that uses his library and works on multiple Scheme implementations, then it will certainly be an impediment to use a Racket-specific value for Nil on Racket, and a Guile-specific value for Nil on Guile. It would be much better to use a portable Scheme data structure uniformly. More generally, even for people only interested in supporting Guile, if they would like their libraries to be usable from Elisp code on Guile, which may become important some day if Guile-Emacs matures, then it's problematic to use #nil for anything that needs to be distinguished from '() or #f. Alternatively, if Guile-Emacs dies and people give up on that project, which is entirely possible, then we should probably deprecate #nil at some point and eventually remove it. Supporting #nil has costs, both in performance and in the size of generated native code, when checking whether an object is true (in every 'if' or 'cond') and when checking for '(). That performance cost is insignificant in an interpreter or VM implementation, but as we move to native code generation it may become significant, as both of the aforementioned operations are quite ubiquitous. Mark