One of the principal virtues of Clojure is its simple design that results in malleable, beautiful composability. Using symbols in place of pointers is a programming practice that has existed for several decades now. It has found widespread adoption in several imperative languages. Clojure dissects that notion in order to uncover the core concerns that need to be addressed. The following subsections illustrate this aspect of Clojure.

We program using logical entities to represent values. For example, a value of 30 means nothing unless it is associated with a logical entity, let's say age. The logical entity age is the identity here. Now, even though age represents a value, the value may change with time; this brings us to the notion of state, which represents the value of the identity at a certain time. Hence, state is a function of time and is causally related to what we do in the program. Clojure's power lies in binding an identity with...

As we've noticed in the previous section, Clojure's data structures are not only immutable, but can produce new values without impacting the old version. Operations produce these new values in such a way that old values remain accessible; the new version is produced in compliance with the complexity guarantees of that data structure, and both the old and new versions continue to meet the complexity guarantees. The operations can be recursively applied and can still meet the complexity guarantees. Such immutable data structures as the ones provided by Clojure are called persistent data structures. They are "persistent", as in, when a new version is created, both the old and new versions "persist" in terms of both the value and complexity guarantee. They have nothing to do with storage or durability of data. Making changes to the old version doesn't impede working with the new version and vice versa. Both versions persist in a...

Sequences (commonly known as seqs) are a way to sequentially consume a succession of data. As with iterators, they let a user begin consuming elements from the head and proceed realizing one element after another. However, unlike iterators, sequences are immutable. Also, since sequences are only a view of the underlying data, they do not modify the storage structure of the data.

What makes sequences stand apart is they are not data structures per se; rather, they are a data abstraction over a stream of data. The data may be produced by an algorithm or a data source connected to an I/O operation. For example, the resultset-seq function accepts a java.sql.ResultSet JDBC instance as an argument and produces lazily realized rows of data as seq.

Clojure data structures can be turned into sequences using the seq function. For example, (seq [:a :b :c :d]) returns a sequence. Calling seq over an empty...

Clojure 1.7 introduced a new abstraction called transducers for "composable algorithmic transformations", commonly used to apply a series of transformations over collections. The idea of transducers follows from the reducing function, which accepts arguments of the form (result, input) and returns result. A reducing function is what we typically use with reduce. A transducer accepts a reducing function, wraps/composes over its functionality to provide something extra, and returns another reducing function.

The functions in clojure.core that deal with collections have acquired an arity-1 variant, which returns a transducer, namely map, cat, mapcat, filter, remove, take, take-while, take-nth, drop, drop-while, replace, partition-by, partition-all, keep, keep-indexed, dedupe and random-sample.

Consider the following few examples, all of which do the same thing:

user=> (reduce ((filter odd?) +) [1 2 3 4 5])
9
user=> (transduce (filter odd?) + [1 2 3 4 5])
9
user=&gt...