---

Clojure Anagrams: The Complete Guide from Zero to Hero

To solve the Anagram challenge in Clojure, you must identify which words from a candidate list are anagrams of a target word. The core logic involves creating a canonical representation for each word by lowercasing and sorting its characters, then comparing these representations while ensuring the original words are not identical.

You’ve just been handed a dataset from a legacy system, and it’s a mess. Words are jumbled, data seems corrupted, and your task is to find hidden relationships within the text. You notice patterns like "least" and "stale," or "owns" and "snow." You realize these aren't random errors; they're anagrams! This classic computer science puzzle isn't just an academic exercise; it's a foundational problem that teaches the art of string manipulation, data normalization, and efficient comparison—skills every developer needs.

Struggling with how to tackle this elegantly in a functional language like Clojure? You're in the right place. This guide will walk you through the entire process, from understanding the core logic to implementing a clean, idiomatic, and efficient solution. We'll demystify Clojure's powerful functions and show you how to think functionally to solve this problem with surprising simplicity.

---

What Exactly is an Anagram?

Before diving into code, it's crucial to establish a crystal-clear definition of an anagram, especially within the context of this specific problem from the kodikra.com learning path. An anagram is a word or phrase formed by rearranging the letters of a different word or phrase, typically using all the original letters exactly once.

For example, the word "listen" is an anagram of "silent" because they both use the exact same set of letters: one 'l', one 'i', one 's', one 't', one 'e', and one 'n'.

For our programming challenge, two specific rules are paramount:

• Case-Insensitivity: The comparison must ignore case. This means "Race" and "care" are considered anagrams. To handle this, we must normalize our input strings to a consistent case (typically lowercase) before any comparison.
• The Self-Exclusion Rule: A word is never its own anagram. For instance, given the target word "stop", the candidate word "stop" should not be included in the result set, even though it technically has the same letters.

Understanding these constraints is the first and most important step. Our entire algorithm will be built around satisfying these two fundamental requirements.

---

Why is This a Foundational Problem in Programming?

The Anagram problem appears simple on the surface, but it serves as an excellent vehicle for teaching and assessing several core programming concepts. It's a staple in technical interviews and coding bootcamps for good reason.

First, it forces you to think about data normalization. Raw input is rarely clean. The need to handle case-insensitivity is a microcosm of real-world data cleaning tasks where you might have to handle different encodings, whitespace, or formats.

Second, it introduces the concept of a canonical representation. This is a powerful idea where you transform complex or varied data into a standard, simplified form to make comparisons easy. For anagrams, sorting the characters of a word (e.g., "care" -> "acer") creates its canonical form. Any word that reduces to the same canonical form is an anagram.

Third, it's a great exercise in algorithmic thinking. As we'll see, there are multiple ways to generate this canonical form, primarily by sorting or by using frequency maps. Analyzing the trade-offs between these approaches (e.g., time and space complexity) is a key skill for any software engineer.

Finally, in a language like Clojure, it beautifully showcases the power of functional programming. We can solve this by composing small, pure functions, leading to code that is declarative, readable, and highly testable.

---

How to Logically Identify an Anagram

The heart of the solution lies in a simple, elegant idea: if you rearrange the letters of two different words and they become identical, they must be anagrams. This "rearrangement" is what we call creating a canonical representation.

Let's break down the logical steps required to check if a candidate word is an anagram of a target word.

Step 1: The Normalization Checkpoint

Our first rule is case-insensitivity. We cannot directly compare "Listen" and "silent". We must first convert both to a common format. Lowercasing is the standard convention.

• "Listen" becomes "listen"
• "silent" becomes "silent"

This ensures that character comparisons in the next step are accurate.

Step 2: Creating the Canonical Form via Sorting

Once both words are in the same case, we need to check if they contain the same letters. The most straightforward way to do this is to sort the characters of each string alphabetically.

• "listen" -> split into characters ('l', 'i', 's', 't', 'e', 'n') -> sort -> ('e', 'i', 'l', 'n', 's', 't')
• "silent" -> split into characters ('s', 'i', 'l', 'e', 'n', 't') -> sort -> ('e', 'i', 'l', 'n', 's', 't')

Since the sorted character sequences are identical, we have a strong indication that they are anagrams. In Clojure, the sort function can operate directly on a string, treating it as a sequence of characters, which simplifies this step immensely.

Step 3: Applying the Self-Exclusion Rule

The final and critical step is to ensure the original (but normalized) words are not the same. The problem states a word cannot be its own anagram.

• Is "listen" (normalized target) different from "silent" (normalized candidate)? Yes.

Therefore, our final logic is a combination of two conditions that must both be true:

1. The sorted, lowercase version of the target word must equal the sorted, lowercase version of the candidate word.
2. The lowercase version of the target word must not equal the lowercase version of the candidate word.

This entire logical flow can be visualized as follows:

    ● Start: (target_word, candidate_word)
    │
    ▼
  ┌─────────────────────────┐
  │ Normalize both to lowercase │
  │ e.g., "Listen" → "listen" │
  │ e.g., "silent" → "silent" │
  └────────────┬────────────┘
               │
               ▼
    ◆ Are normalized words identical?
   ╱            ╲
  Yes (e.g., "stop", "stop")      No (e.g., "listen", "silent")
  │                               │
  ▼                               ▼
┌──────────────┐             ┌───────────────────┐
│ NOT an anagram │             │ Sort characters of each │
│ (Rule Violation) │             │ "listen" → ('e','i','l','n','s','t') │
└──────────────┘             │ "silent" → ('e','i','l','n','s','t') │
      │                      └──────────┬──────────┘
      │                                 │
      └───────────┐                     ▼
                  │              ◆ Are sorted sequences equal?
                  │             ╱            ╲
                  │            Yes            No
                  │            │              │
                  │            ▼              ▼
                  │      ┌──────────┐   ┌──────────────┐
                  └─────▶│ ANAGRAM! │   │ NOT an anagram │
                         └──────────┘   └──────────────┘

---

Where to Implement the Solution: A Clojure Code Walkthrough

Now, let's translate our logic into idiomatic Clojure code. The solution provided in the kodikra module is concise and perfectly captures the functional approach. We'll break it down piece by piece to understand how it works.

The solution is typically split into two functions: a private helper function to check a single pair of words, and a public function to filter a collection of candidates.

The Complete Code Snippet

(ns anagram
  (:require [clojure.string :as str]))

(defn- anagram?
  "Private helper function to determine if a candidate `c` is an anagram of word `w`."
  [w c]
  (let [w-lower (str/lower-case w)
        c-lower (str/lower-case c)]
    (and (= (sort w-lower) (sort c-lower))
         (not= w-lower c-lower))))

(defn anagrams-for
  "Filters a collection of candidates to find anagrams for a given word."
  [word candidates]
  (filter (partial anagram? word) candidates))

Line-by-Line Breakdown of anagram?

This is our core logic function. The defn- macro defines a "private" function, meaning it's intended to be used only within the current namespace (anagram). This is good practice for helper functions that aren't part of the public API.

(defn- anagram? [w c] ... )

• (defn- anagram? [w c]): Defines a private function named anagram? that takes two arguments: w for the target word and c for the candidate word.

(let [w-lower (str/lower-case w)
      c-lower (str/lower-case c)]

• (let [...]): A let block creates local bindings. This is used to avoid repetitive computations and make the code cleaner. Here, we're performing our normalization step.
• w-lower (str/lower-case w): We call the lower-case function from the clojure.string library (aliased as str) on the target word w and bind the result to w-lower.
• c-lower (str/lower-case c): We do the same for the candidate word c, binding the result to c-lower.

(and (= (sort w-lower) (sort c-lower))
     (not= w-lower c-lower)))

• This is the implementation of our two-part logical check. The (and ...) macro evaluates its arguments in order and returns the last one if all are truthy, otherwise it returns false or nil.
• (= (sort w-lower) (sort c-lower)): This is the first condition.
  • (sort w-lower): In Clojure, a string is a sequence of characters. The sort function naturally operates on this sequence, returning a sorted sequence of characters.
  • (= ...): We use the equality operator to check if the sorted character sequence of the target word is identical to that of the candidate word. This is our canonical representation check.
• (not= w-lower c-lower): This is our second condition, the self-exclusion rule.
  • (not= ...): This checks for inequality. We ensure that the normalized original words are not the same.

Line-by-Line Breakdown of anagrams-for

This is the public API function. It takes the target word and a collection of potential candidates and returns only those that are valid anagrams.

(defn anagrams-for [word candidates] ... )

• (defn anagrams-for [word candidates]): Defines a public function named anagrams-for that takes a word (the target) and a candidates collection.

(filter (partial anagram? word) candidates)

• (filter ... candidates): The filter function is a cornerstone of functional programming. It takes a predicate function and a collection, and returns a new sequence containing only the items from the original collection for which the predicate returned a truthy value.
• (partial anagram? word): This is where the magic happens. partial is a higher-order function that takes another function and some of its arguments, and returns a *new* function that "waits" for the remaining arguments.
  • Our anagram? function needs two arguments: `w` and `c`.
  • (partial anagram? word) creates a new, anonymous function that looks like (fn [c] (anagram? word c)). It has "pre-filled" the first argument of anagram? with our target word.
  • This new function is the perfect predicate for filter. For each item in the candidates collection, filter will call this new function with the candidate as the single argument.

This use of partial and filter is extremely idiomatic and demonstrates the power of composing functions in Clojure to create expressive and concise data processing pipelines.

---

When to Optimize: An Alternative Using Frequency Maps

The sorting-based solution is elegant, readable, and often sufficient. However, it's not the only way. For a computer science enthusiast or someone preparing for an interview, it's crucial to know alternative approaches and their performance characteristics.

Another way to create a canonical representation is by counting the frequency of each character in a word. If two words have the exact same character frequency map, they must be anagrams.

The Frequency Map Logic

1. Normalize the word to lowercase.
2. Create a map where keys are characters and values are their counts.
   • "listen" -> {\l 1, \i 1, \s 1, \t 1, \e 1, \n 1}
   • "silent" -> {\s 1, \i 1, \l 1, \e 1, \n 1, \t 1}
3. Compare the frequency maps. In Clojure, two maps are equal if they have the same set of keys and each key maps to the same value. The order of keys doesn't matter.

Implementation with frequencies

Clojure has a built-in function, frequencies, that does exactly this! It takes a collection and returns a map of items to their counts.

;; An alternative implementation of anagram?
(defn- anagram-freq?
  [w c]
  (let [w-lower (str/lower-case w)
        c-lower (str/lower-case c)]
    (and (not= w-lower c-lower)
         (= (frequencies w-lower) (frequencies c-lower)))))

;; The public function would then use this new helper
(defn anagrams-for-freq
  [word candidates]
  (filter (partial anagram-freq? word) candidates))

Performance Comparison: Sorting vs. Frequency Map

This is a classic algorithmic trade-off discussion.

• Sorting Approach: The dominant operation is sorting the string. A typical efficient sorting algorithm has a time complexity of O(N log N), where N is the length of the string.
• Frequency Map Approach: The dominant operation is iterating through the string once to build the map. This has a time complexity of O(N), where N is the length of the string.

Theoretically, the frequency map approach is faster (linear time vs. log-linear time). In practice, for very short strings, the overhead of creating hash maps might make the sorting approach competitive or even slightly faster. However, as strings get longer, the O(N) performance of the frequency map method will decisively win out.

Here is a diagram comparing the two algorithmic flows:

     ● Input: ("Listen", "silent")
     │
     ├─────────────────────────────┬────────────────────────────┐
     ▼                             ▼                            ▼
┌──────────────────┐          ┌──────────────────┐         ┌──────────────────┐
│  Sorting Method  │          │ Frequency Method │         │ Common Steps     │
└──────────────────┘          └──────────────────┘         └──────────────────┘
     │                             │                            │
     ▼                             ▼                            ▼
┌──────────────────┐          ┌──────────────────┐         ┌──────────────────┐
│ Lowercase:       │          │ Lowercase:       │         │ Lowercase Check: │
│ "listen", "silent" │          │ "listen", "silent" │         │ "listen" != "silent" → True
└────────┬─────────┘          └────────┬─────────┘         └──────────────────┘
         │                             │
         ▼                             ▼
┌──────────────────┐          ┌──────────────────┐
│ Sort Chars:      │          │ Build Freq Map:  │
│ 'e','i','l','n','s','t' │          │ {\l 1, \i 1, ...} │
└────────┬─────────┘          └────────┬─────────┘
         │                             │
         ▼                             ▼
┌──────────────────┐          ┌──────────────────┐
│ Compare Sorted   │          │ Compare Maps     │
│ Seqs: Equal → True │          │ Equal → True     │
└────────┬─────────┘          └────────┬─────────┘
         │                             │
         └─────────────┬───────────────┘
                       ▼
            ◆ Both checks passed?
            │
            ▼
        ● Result: Anagram

---

Frequently Asked Questions (FAQ)

1. What is the difference between defn and defn- in Clojure?

defn defines a standard, public function that can be accessed from other namespaces. defn- defines a private function. The hyphen at the end is a Clojure convention to indicate privacy. Private functions are only accessible within the namespace they are defined in, which is a great way to encapsulate implementation details and expose a clean public API.

2. Why use (partial anagram? word) instead of an anonymous function like #(anagram? word %)?

Both achieve the same result. Using (partial f x) is often considered more "idiomatic" or expressive in the Clojure community when you are simply pre-filling the first few arguments of a function. The anonymous function literal #(...) is more general and powerful, especially if you need to rearrange arguments or perform other logic. In this specific case, it's a matter of style, and both are perfectly valid and efficient.

3. How does sort work on a string in Clojure?

In Clojure, strings are treated as sequences of characters. Most core sequence functions, including sort, map, and filter, can operate on them directly. When you call (sort "bca"), Clojure iterates through the string as if it were a list (\b \c \a) and returns a new sorted sequence of characters: (\a \b \c).

4. Can this solution handle Unicode characters?

Yes, for the most part. Clojure strings are Java strings, which are sequences of UTF-16 characters. Both clojure.string/lower-case and sort will work correctly with most Unicode characters. However, be aware of complex Unicode concepts like grapheme clusters (e.g., an emoji made of multiple code points) or locale-specific casing rules, which might require more advanced libraries if precise handling is needed.

5. Is the frequency map approach always faster in practice?

While its time complexity is asymptotically better (O(N) vs. O(N log N)), it's not always faster in the real world. For very short strings, the constant factors matter. Creating hash maps and calculating hash codes has some overhead. The performance of Java's `Arrays.sort()` (which Clojure's `sort` might use under the hood) is highly optimized. You would likely need to benchmark with your expected data size to be certain, but for longer strings (e.g., > 20-30 characters), the frequency map approach will almost certainly be faster.

6. How would I adapt this solution to handle anagrams of phrases with spaces, like "school master" and "the classroom"?

You would need to modify the normalization step. Before lowercasing, you would first remove all non-alphabetic characters (like spaces and punctuation). You could use a regular expression for this. For example: `(str/replace s #"[^a-zA-Z]" "")` would remove everything that isn't a letter before you proceed with lowercasing and sorting/frequency mapping.

---

Conclusion: The Elegance of Functional Problem-Solving

We've journeyed from a simple definition to a deep, functional implementation for solving the Anagram problem in Clojure. The key takeaways are rooted in a clear, logical process: first, normalize your data by handling case-insensitivity; second, create a canonical representation to make comparison trivial, either through sorting or frequency mapping; and third, meticulously apply all problem constraints, like the self-exclusion rule.

The Clojure solution highlights the beauty of the language's design. By composing higher-order functions like filter and partial with pure, focused helper functions, we built a data processing pipeline that is not only efficient but also remarkably readable and declarative. This approach is a testament to the power of thinking functionally.

Whether you choose the elegant simplicity of sorting or the theoretical performance of frequency maps, you now have the tools and understanding to tackle this and similar challenges with confidence. This foundational module from the kodikra curriculum is a stepping stone to mastering data manipulation in any language.

Disclaimer: All code examples and explanations are based on Clojure version 1.11+ and standard Java Virtual Machine (JVM) environments. Future language versions may introduce new functions or optimizations, but the core logic and algorithms presented here are timeless.

Ready to continue your journey? Explore the complete Clojure Learning Path on kodikra.com or dive deeper into our comprehensive Clojure curriculum to master the art of functional programming.

---

Published by Kodikra — Your trusted Clojure learning resource.