In some languages and data serialization formats, there is an additional constant besides true and false, null.

These include JSON and its derivatives such as YAML, but also SQL. In the latter case, the third boolean constant is used in a real three-valued logic system, which someone may also want to write a library for in Scheme.

JSON serialization and deserialization libraries often struggle with how to represent JSON’s null. Since lists are often used either to represent JSON’s arrays or objects (as alists), the Scheme empty list is inappropriate as it would be ambiguous what the type was in the original JSON source.

DSLs for SQL databases also need a way to represent the null value. The above problem with JSON also affects database access in trendy schemaless databases like CouchDB, as well as SQL databases like PostgreSQL which have JSON column storage types.

Then of course there is the use-case of FFIs to languages such as Ruby, Python, and (especially these days) JavaScript which have such constants. (JavaScript has two of them, even, sigh. But I don’t propose adding an ‘undefined’ constant as well.)

I therefore propose adding a special constant to Scheme to represent null, specifically for use at the boundaries between Scheme and other programming systems which distinguish this extra value. Note that these use cases are very distinctly different to those of the Maybe type of SRFI 189.

The null value is a single global constant: it can’t be instantiated more than once and nothing is eq? to it other than itself.

Bikeshed argument agenda:

• Since the predicate name ‘null?’ is used to test for the empty list, anything to do with ‘null’ is probably a bad idea. ‘nil’ could work but would likely just confuse. Other options are ‘none’, ‘nothing’, ‘void’, ‘unknown’, …

• A portable way to implement this would a procedure or macro which returns/expands to this single value. So you have to evaluate (none), or a similar expression, to get the value. But giving it reader notation like #none or #0 or #∅ or similar would make it available in non-evaluated contexts, a significant benefit.

• It would be most practical to maintain #f as the only value which is false in Scheme’s built-in boolean contexts, but this may be somewhat counter-intuitive. (I certainly don’t propose adding Kleene’s three-valued logic to Scheme’s core, even if providing operators for this would be an obvious Scheme-native application of the value.)

Daphne