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 00:52:27 -0400 Message-ID: <8736v0v2b8.fsf@netris.org> References: <21036238.c6yQEfjfIL@aleksandar-ixtreme-m5740> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1535345545 3043 195.159.176.226 (27 Aug 2018 04:52:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 27 Aug 2018 04:52:25 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: guile-user@gnu.org, hiphish@posteo.de To: John Cowan Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Aug 27 06:52:20 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 1fu9Vj-0000gB-RE for guile-user@m.gmane.org; Mon, 27 Aug 2018 06:52:19 +0200 Original-Received: from localhost ([::1]:51308 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fu9Xp-0001uA-QR for guile-user@m.gmane.org; Mon, 27 Aug 2018 00:54:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35460) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fu9XU-0001u2-T9 for guile-user@gnu.org; Mon, 27 Aug 2018 00:54:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fu9XQ-0006oT-9P for guile-user@gnu.org; Mon, 27 Aug 2018 00:54:08 -0400 Original-Received: from world.peace.net ([64.112.178.59]:46680) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fu9XQ-0006o3-55 for guile-user@gnu.org; Mon, 27 Aug 2018 00:54:04 -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 1fu9XO-0000dS-B8; Mon, 27 Aug 2018 00:54:02 -0400 In-Reply-To: (John Cowan's message of "Sun, 26 Aug 2018 13:49:29 -0400") 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:14773 Archived-At: John Cowan writes: > Well, you could use #nil, a Guile-specific unique object that is both falsy > (like #f) and answers #t to the null? predicate. It is used to emulate > Common Lisp's and Elisp's nil. As I wrote earlier, I would avoid using #nil for anything outside of its intended use case. > But a more portable approach would be to define a record type with no > slots and make just one instance of it. If _all_ symbols must be distinguishable from the "nothing" object, then John's suggestion is a fine solution. To avoid unnecessary heap allocation, you should indeed arrange to make only one instance of it, as John said. However, in most cases, symbols are precisely what's needed to represent distinguished atomic objects such as this. I looked at and I don't see why a symbol couldn't be used to represent MessagePack's 'nil'. I hope that HiPhish is not planning to use symbols to represent MessagePack strings. That would be an abuse of symbols, IMO. Symbols are intended to represent atomic objects (i.e. objects containing no internal structure) whose only essential operation is to compare them for equality. A practical problem with using symbols to represent strings is that symbols need to be "interned", i.e. stored in a global hash table, to ensure that any two symbols containing the same sequence of characters are represented by the same object. A consequence of this is that every time a new symbol is encountered, it must be added to the global hash table, which in turn must be protected by a mutex. This would slow down creation of MessagePack strings, especially if several threads are doing it concurrently, to no good end that I can see. Mark