# Why does Clojure continue to draw so much creativity?

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com, or follow me on Twitter.

As explained before, the core of Specter is the defnav operator upon which Specter’s entire collection of navigators is built. Specter’s extensibility is one of its most important features, as you may use data structures other than the ones Clojure provides. As I mentioned, I do a lot of work with graphs, and I just wouldn’t be able to work with them in any reasonable way without my internal collection of graph navigators (e.g. subgraph, topological traversal, to a node id, to outgoing nodes, to incoming nodes, etc.).

Specter’s navigator interface is completely generic, able to express any navigator. Let’s see how it works by looking at the implementation of a simple navigator, NAMESPACE:

(defnav ^{:doc "Navigates to the namespace portion of the keyword or symbol"}
NAMESPACE
[]
(select* [this structure next-fn]
(next-fn (namespace structure)))
(transform* [this structure next-fn]
(let [name (name structure)
new-ns (next-fn (namespace structure))]
(cond (keyword? structure) (keyword new-ns name)
(symbol? structure) (symbol new-ns name)
:else (i/throw-illegal "NAMESPACE can only be used on symbols or keywords - " structure)
))))


There are two codepaths, one for querying (select*) and one for transforming (transform*). Querying in Specter works very similar to how transducers work. It achieves great performance by avoiding the creation of any intermediate data structures. In this case, it navigates to the namespace of the value by calling next-fn on it. A navigator that navigates to multiple subvalues (like ALL) must call next-fn on each subvalue. (As an aside, select* used to work exactly like the list monad. However, materializing intermediate lists during navigation killed performance so the method was changed in 0.12.0 to avoid that problem.)

Source