Re: A value for "nothing"

[Mark H Weaver]

John Cowan <address@hidden> 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