List of Figures

Chapter 1. Introducing Clojure

Figure 1.1. Representation of a tree of values called xs. Used with permission from https://commons.wikimedia.org/wiki/File:Purely_functional_tree_before.svg.

Figure 1.2. Representation of new tree ys. Used with permission from https://commons.wikimedia.org/wiki/File:Purely_functional_tree_after.svg.

Figure 1.3. Parentheses for calling functions

Figure 1.4. Nested parentheses for calling functions

Chapter 4. Multimethod polymorphism

Figure 4.1. The hierarchy of profit rating levels as explained by the business folks. You can use this external-facing classification to simplify your code by defining a dispatch hierarchy reflecting this structure.

Chapter 5. Exploring Clojure and Java interop

Figure 5.1. Typical organization of a Clojure project. The src directory contains the source code, organized in a similar way to Java packages.

Figure 5.2. Adding two new files, dcf.clj and fcf.clj, in a subdirectory of utils that have code for the same com.curry.utils.calculators namespace.

Chapter 6. State and the concurrent world

Figure 6.1. It’s important to recognize the separation between what we’re talking about (say, favorite movies, which is an identity) and the values of that identity. The identity itself never changes, but it refers to different values over time.

Figure 6.2. A reference that points to completely different immutable values over time

Figure 6.3. The thread pool used for the send function is fixed based on the number of cores available. If all the threads are busy, then functions get queued.

Chapter 7. Evolving Clojure through macros

Figure 7.1. Phases of the Clojure runtime. This separation is what makes the macro system possible.

Chapter 8. More on functional programming

Figure 8.1. The tax-rate initially passed into the price-calculator-for-tax function is captured by the resulting function (such as price-with-ca-tax). It’s then able to use that value when it’s called with a price, to return the correct price with the tax applied to it.

Figure 8.2. The minimal object system you’ve built implements a major portion of features that are supported by most common OO systems. Everything ultimately derives from a common entity called OBJECT. Instances look up the class they derive from and look up methods there. Methods can also be looked up in the chain of hierarchy.

Chapter 9. Protocols, records, and types

Figure 9.1. Calling def-modus-operandi creates a var that will hold information about the modus operandi that can later be used to introspect it. The macro itself makes as many calls to defmulti as needed. The detail-modus-operandi macro is the other side of the modus operandi concept: it fills out the implementation details by expanding to as many defmethod calls as specified. It also updates the modus-operandi var to reflect the implementor information.

Figure 9.2. Calling defprotocol performs an analogous operation where a var is created to hold information about the protocol and its implementors. The underlying implementation will also result in a Java interface that pertains to the protocol being defined. Calls to extend, extend-type, and extend-protocol will update the var with implementor details and generate Java classes that implement the protocol.

Chapter 11. More macros and DSLs

Figure 11.1. As usual, the Clojure reader first converts the text of your programs into data structures. During this process, macros are expanded, including the def-rot-encrypter macro, which generates a tableau. This tableau is a Clojure map and is included in the final form of the source code as an inline lookup table.

Figure 11.2. The typical layers in a DSL-driven system. Such systems benefit from a bottom-up design where the lowest levels are the primitive concepts of the domain modeled on top of the basic Clojure language. Higher layers are compositions of these primitives into more complex domain concepts. Finally, a runtime layer sits on top of these, which can execute code specified in a DSL. This final layer often represents the core solution of the problem that the software was meant to solve.