Kelly Innes dot com    About


updated May 25, 2015

Here’s a very functional blog post: an ongoing catalogue of the “falsy” values in various programming languages. Prerequisite reading material: the Boolean data type article on Wikipedia.

What provoked it? A passage in that David Foster Wallace book Everything and More:

…0 v. nothing is one of those abstract distinctions that’s almost impossible to talk about directly; you more have to do it with examples. Imagine there’s a certain math class, and in this class there’s a fiendishly difficult 100-point midterm, and imagine that neither you not I get even one point out of 100 on this exam. Except there’s a difference: you are not in the class and didn’t even take the exam, whereas I am, and did. The fact that you received 0 points on the exam is thus irrelevant – your 0 means N/A, nothing – whereas my 0 is an actual 0.


C turns out not to have Booleans, and it uses numerical values instead. Here’s a snippet from this Introduction to C Programming:

In C true is represented by any numeric value not equal to 0 and false is represented by 0. This fact is usually well hidden and can be ignored, but it does allow you to write

if(a != 0) just as if(a)

because if a isn’t zero then this also acts as the value true. It is debatable if this sort of shortcut is worth the three characters it saves.

Common Lisp

The basic false value in Common Lisp is the empty list. Here’s a relevant excerpt from Common Lisp: The Language:

In Common Lisp, as in most Lisp dialects, the symbol nil is used to represent both the empty list and the “false” value for Boolean tests. An empty list may, of course, also be written (); this normally denotes the same object as nil. (It is possible, by extremely perverse manipulation of the package system, to cause the sequence of letters nil to be recognized not as the symbol that represents the empty list but as another symbol with the same name. This obscure possibility will be ignored in this book.) These two notations may be used interchangeably as far as the Lisp system is concerned. … Any data object other than nil is construed to be Boolean “not false”, that is, “true”. The symbol t is conventionally used to mean “true” when no other value is more appropriate. When a function is said to “return false” or to “be false” in some circumstance, this means that it returns nil. However, when a function is said to “return true” or to “be true” in some circumstance, this means that it returns some value other than nil, but not necessarily t.


“Naming rules are very important in maintainable INTERCAL code, due to the lack of local variables or local labels or really any kind of scoping whatsoever.” That’s from this INTERCAL Style Guide, and I don’t really understand it and looking through the “Revamped INTERCAL Instruction Manual” didn’t help.

This article from the esolangs wiki seems slightly more helpful. But only slightly.

Googling around a bit more led me to this Reddit comment:

INTERCAL programmers typically use 1 and 2 as the true and false values (either way round, it can vary from place to place in a program), because that’s what’s easiest to use in a conditional. 0 and 1 has been spotted in the wild, though, especially in more recent code (it works better with computed COME FROM).

Some people used to use 2 and 3, but that tend to make life easier for library writers at the expense of making it slightly harder for library users. The use is discouraged nowadays, at least by me.


Here’s a pretty concise SitePoint blog post about Truthy and Falsy values in JavaScript. In its words “everything in JavaScript has an inherent Boolean value, generally known as either truthy or falsy” and here’s its catalog of values that are always falsy:

  • false
  • 0
  • "" (an empty string)
  • null
  • undefined
  • NaN

JavaScript also makes a distinction between its identity comparison operator (===) and its equality comparison operator (==). This StackOverflow answer explains that “the == operator will compare for equality after doing any necessary type conversions” while === does not do any conversion, so returns false if two values aren’t already of the same type.

The difference helped elicit this JavaScript Equality Table.


From the online Programming in Lua book:

2.2 – Booleans

The boolean type has two values, false and true, which represent the traditional boolean values. However, they do not hold a monopoly of condition values: In Lua, any value may represent a condition. Conditionals (such as the ones in control structures) consider false and nil as false and anything else as true. Beware that, unlike some other scripting languages, Lua considers both zero and the empty string as true in conditional tests.

Pascal’s docs explain that Free Pascal’s Boolean type has the two expected possible values. The docs also note that “any expression that resolves to a Boolean value, can also be assigned to a boolean type.”

The language also includes a few other Boolean types: ByteBool, WordBool, and LongBool. It seems like these aren’t strictly Boolean types, but they evaluate to the correct Boolean value when used in a Boolean context.

Free Pascal also supports “short-cut boolean evaluation”: once the truth-value of an expression is known, the rest of the expression gets skipped.


Perl doesn’t have Boolean data types, but it does have Boolean contexts: scalar contexts in which an expression’s evaluated as true or false. A scalar context is, roughly speaking, a spot where an expression’s evaluated in the singular (a list context evaluates an expression in the plural). The Camel book describes “the technical definition that Perl uses” when evaluating in a Boolean context:

a scalar value is true if it is not the null string "" or the number 0 (or its string equivalent "0"). A reference is always true because it represents an address which is never 0. An undefined value (often called undef) is always false because it looks either like "" or 0, depending on whether you treat is as a string or a number. (List values have no Boolean value because list values are never produced in a scalar context!)

According to this site, the empty list () is also false.


As this blog post explains, false and nil are the only falsy values in Ruby. But since everything in Ruby’s an object and everything instance’s a class, false and nil each have their own classes: FalseClass and NilClass, respectively. Here’s what the Pickaxe says about FalseClass:

The global value false is the only instance of the class FalseClass and represents a logically false value in Boolean expressions. The class provides operators allowing false to participate correctly in logical expressions.

Likewise the NilClass only has once instance: nil. The Pickaxe describes its xor instance method like this:

^ : Exclusive Or – Returns false if object is nil or false and returns true otherwise.

Let’s try it in irb:

2.0.0-p451 :001 > a = 0
 => 0 
2.0.0-p451 :002 > nil ^ a
 => true
2.0.0-p451 :010 > nil ^ false
 => false

My favorite part of that earlier blog post, btw, is totally this comment about extending the NilClass like this:

class NilClass
  def makedate
    Time.parse("1980-01-01 00:00:00")


Probably never do that.


From the docs for MIT Scheme:

In Scheme, the Boolean values true and false are denoted by #t and #f. However, any Scheme value can be treated as a Boolean for the purpose of a conditional test. This manual uses the word true to refer to any Scheme value that counts as true, and the word false to refer to any Scheme value that counts as false. In conditional tests, all values count as true except for #f, which counts as false.


The traditional UNIX shell apparently doesn’t include Boolean data types. According to this bit on UNIX Shell Boolean Values from, “Truth is determined by exit codes rather than values”:

The evaluation of true and false within the shell is different to the evaluation of truth from within a high level language. Within the shell, a truth is based on the exitcode of the last command in the evaluation block:

  • An exitcode of zero is considered to be a true condition
  • An exitcode of nonzero is considered to be a false condition

Apparently even conditional statements use exit codes to check for truth values. This Bash Beginner’s Guide notes that for an if TEST-COMMANDS;... conditional statement

The TEST-COMMAND list is executed, and if its return status is zero, the CONSEQUENT-COMMANDS list is executed. The return status is the exit status of the last command executed, or zero if no condition tested true.

more soon