Strings represent textual data, as a sequence of characters. They can be entered as literals in a ClojureScript program using double quotes. Although they are primitives, it is also possible to obtain a sequence view of a string as a sequence of characters (see the next chapter).

Under the hood, ClojureScript strings are JavaScript strings, and may be freely passed to (or received from) JavaScript functions and libraries that expect (or return) strings.

Keywords are very similar to strings in that they are sequences of characters. Actually, in ClojureScript, they are nearly identical to strings except for their intended use. Typically keywords are used as keys in maps, for constants, or for enumerated sets of values. As a rule of thumb, it is idiomatic to use a keyword wherever the value is of interest to the program or programmer, rather than data for the user.

In Clojure, keywords are guaranteed to be interned (that is, all instances of the same keyword will always refer to the same object in memory, making them very efficient). This is not the case in ClojureScript, since at the JavaScript level keywords are implemented as plain old JavaScript strings. Still, it is good practice to create keywords only for a constrained, finite set of values.

Keywords may optionally be namespace qualified, meaning that they have a separate namespace component to them, and are logically associated with a particular namespace (namespaces are discussed in Chapter 7). To create a namespace-qualified keyword as a literal, include a slash in the keyword. For example, :my-ns/foo creates a keyword with a name of “foo” in a namespace called “my-ns.” You can also use a double leading colon to create a namespace-qualified keyword in the current namespace (e.g., ::foo).

Keywords also support some additional operations; for example, they can be used as functions that know how to look themselves up in maps, which we will see later.

Symbols are also very similar to strings, and like keywords, they can be namespace-qualified. In ClojureScript they are used almost exclusively as named bindings (i.e., “variable” names, even though ClojureScript doesn’t really have variables as such). The literal form of a symbol is simply the raw text (foo), with a slash if it is namespace-qualified (foo/bar).

There is typically no reason to create or use symbols as data in your program, unless you’re working with macros (discussed in Chapter 8). Although they’re a key part of the data that represents your program itself (remember, Lisp code is data), keywords or strings are usually better choices for the data your program actually manipulates.

In ClojureScript, symbols are also implemented as JavaScript strings.

Characters are a single textual character, and can be expressed as literals with a leading backslash (e.g., a for the character “a”).

Since JavaScript doesn’t have a native character type, ClojureScript characters are implemented as single-character strings, and behave identically to strings.

ClojureScript’s numbers are the same as JavaScript numerics and can be either integers or floating-point numbers. They are expressed literally as numerals (for example, 42 or 3.14). Conversions and coercions between integer and floating point happen automatically; ClojureScript has the same arithmetic semantics as JavaScript.

You can pass a ClojureScript numeric value to any JavaScript function that expects a numeric, and receive them the same way.

Unlike Clojure, ClojureScript does not currently support additional numeric types such as Ratio, BigDecimal, or BigInteger.

Boolean values are always one of two values, true or false, representing logical truth and falsehood, respectively. ClojureScript Booleans, like strings and numerics, are implemented directly as JavaScript Boolean values and may be used accordingly in interop scenarios.

To use a Boolean as a literal, just type one of the special symbols true or false.

In ClojureScript (like JavaScript), functions are first-class entities and, as befits a functional programming language, are themselves data. They can be created using the syntax discussed in the previous chapter, and once created can be passed around and added to composite data structures like any other data.

Importantly, ClojureScript functions are implemented as plain old JavaScript functions. This means that they can be passed to any JavaScript library that takes a function as a callback (for example), and given a JavaScript function, you can invoke it using ClojureScript syntax. (Unless, of course, the JavaScript function contains a reference to this. Internally, ClojureScript always invokes functions using their call method and passes in nil as the value for this.)

ClojureScript’s nil is identical to null in JavaScript; it is used where a value is logically absent, empty, or meaningless. To use it as a literal, just use the special symbol nil. ClojureScript does not use JavaScript’s undefined value, but you can refer to it as js/undefined.

An important feature of all of ClojureScript’s collections is that they are immutable, meaning that they can’t be changed. Functions that “modify” collections don’t actually ever change them, but instead create and return a new one based on the original with the specified differences in place.

This is highly nonintuitive to most programmers who don’t have prior experience with purely functional languages. However, it becomes clearer once you understand Clojure(Script)’s concept of value.

Values don’t change. Consider the number 3. If you add 3 + 1, you haven’t changed the value of 3 (which would wreak havoc with math and physics everywhere). Instead, you’ve acquired a new value. The same is true of words: if you use the word “good” together with the word “morning” to say “good morning,” you haven’t changed the global meaning of the word “good,” you’ve used it to create a new utterance. In ClojureScript, the very definition of a value means that it can’t change—if it does, it’s no longer the same value.

ClojureScript’s collections are all values. If I take the vector [1 2] and append the value 4, I haven’t changed the meaning of [1 2]. I can’t change it. By definition, it can only ever mean “the two element vector consisting of the integers 1 and 2.” If I could literally change it, it would no longer meet its own definition. But what I can do is create an entirely new vector, using [1 2] as a base: [1 2 4].

The same thing is true of all ClojureScript’s other collection types. When you add a member to a set, you’re creating a different set with different members (which, incidentally, conforms to the mathematical definition of a set). When you add an item to the front of a list, you create a new list consisting of both the old list and the new item. When you add a new key to a map, you’re creating a new map, with a different set of keys.

One question that almost invariably follows a discussion of immutability is that of the performance implications. No matter what the benefits are, isn’t cloning an entire data structure every time it’s updated prohibitively wasteful of computational resources?

The answer would be yes, if that were what actually happens. Fortunately, ClojureScript provides some extremely sophisticated data structure implementations that utilize the concept of persistence to provide objects that are logically immutable, but share structure with previous versions of themselves to minimize their computational overhead.

A full discussion of the implementation of persistent data structures is beyond the scope of this book, but essentially what happens is that when a data structure is modified, the new value is not a full clone of the original one. Instead, it incorporates the original (which it can safely do, because the old one is immutable) plus the changes, and then exposes a unified view of the whole package in a way that hides the internal structure.

In practical terms, persistence means that while using immutable objects does incur some small overhead compared with mutating traditional objects, it (hopefully) falls well within the realm of acceptable cost relative to the benefit provided. Typically, unless you’re writing extremely performance-sensitive code (which is rare in JavaScript to begin with), ClojureScript’s immutable collections are more than fast enough. And if you ever do need to eke out every last drop of performance, ClojureScript’s interop syntax makes it easy to drop down to native JavaScript objects and arrays.

In Clojure, there are several constructs for creating identities, including atoms, refs, and agents. The different types of identities differ in the concurrency semantics they support. In ClojureScript, which doesn’t need to support shared-memory concurrency, there is only one type: atoms.

Atoms are identities that refer to a single value (though that value, of course, may be one of Clojure’s collections). All updates to the state of an atom are atomic, that is, they occur in a single operation.

To create an atom, just use the atom function, passing a value for the initial state. For example:

(def my-atom (atom {}))

This constructs an atom with an initial state of an empty map, and binds it to a var called my-atom.

To retrieve the current value of an atom, use the deref function, which also has a shortened syntax using the reader macro @. The following two expressions are equivalent:

(deref my-atom)   ;=> {}
@my-atom   ;=> {}

There are two ways to update the state of an atom, swap! and reset!. swap! is used to update the atom’s state in terms of the previous state, reset! sets the state without regard for the previous state. Both functions return the value of the atom’s new state.

swap! always takes at least two arguments; the first is the atom, the second is the update function. The update function will be applied with the value of the atom as its first argument, with any additional arguments to swap! used as additional arguments.

So, for example, to add a new entry to the map that is the current value of my-atom, you could invoke swap! like so:

(swap! my-atom assoc :a "1")  ;=> {:a 1}

Subsequently, retrieving the value of the atom returns the new value:

@my-atom   ;=> {:a 1}

Or, you can use reset!, passing the atom and the new value to update the state:

(reset! my-atom {:x 42})  ;=> {:x 42}
@my-atom   ;=> {:x 42}

Initially, this might seem like too much ceremony to do something as easy as changing some state. But the ceremony is (almost) the whole point. State should not be something implicit in a program, quietly multiplying complexity exponentially with each new variable. Instead, it should be carefully, knowingly managed. In ClojureScript, atoms provide this capability.