John Cowan <[email protected]> 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 <https://en.wikipedia.org/wiki/MessagePack> 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
