# clojure functions Published articles for clojure functions. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Clojure: Combining Calls To Doseq And Let DevFeed: [Clojure: Combining Calls To Doseq And Let]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2013-05-16T12:00:00Z Content type: tutorial Language: en Sources: [Jay Fields]() Topics: [Clojure](), [function](), [iteration](), [Code]() Tags: [clojure](), [clojure-functions](), [code](), [function](), [iteration](), [modifiers]() ### AI overview This Clojure tutorial explains that doseq supports the :let, :when, and :while modifiers also available in the for macro. It compares multiple doseqs with multiple bindings, noting that binding choices can change how often functions are evaluated and that :let can control evaluation frequency. ### Source excerpt I've you've ever looked at the docs for clojure's for macro, then you probably know about the :let, :when, and :while modifiers. What you may not know is that those same modifiers are available in doseq. I was recently working with some code that had the following form. Upon seeing this code, John Hume asked if I preferred it to a single doseq with multiple bindings. He sent over an example that looked similar to the following example. That was actually the first time that I'd seen multiple bindings in a doseq, and my immediate reaction was that I preferred the explicit simplicity of having multiple doseqs. However, I always have a preference for concise code, and I forced myself to starting using multiple bindings instead of multiple doseqs - and, unsurprisingly, I now prefer multiple bindings to multiple doseqs. You might have noticed that the second version of the code slightly changes what's actually being done. In the original version the 'name' function is called once per 'id', and in the second version the 'name' function is called once per 'sub-id'. Calling name significantly more often isn't likely to have much impact on your program; however, if you were calling a more expensive function this change could have a negative impact. Luckily, (as I previously mentioned) doseq also provides support for :let. The second example can be evolved to the following code - which also demonstrates that the let is only evaluated once per iteration. That's really the final version of the original code, but you can alter it slightly for experimentation purposes if you'd like. Let's assume we have another function we're calling in an additional let and it's expensive, it would be nice if that only occurred when an iteration was going to happen. It turns out, that's exactly what happens. Whether you prefer multiple bindings or multiple doseqs, it's probably a good idea to get comfortable reading both. © Jay Fields - www.jayfields.com ## Clojure: Testing The Creation Of A Partial Function DevFeed: [Clojure: Testing The Creation Of A Partial Function]() Original publisher: [Read original article]() Author: Jay (noreply@blogger.com) Published: 2013-05-14T12:00:00Z Content type: article Language: en Sources: [Jay Fields]() Topics: [Clojure](), [Testing](), [Refactoring](), [function]() Tags: [clojure](), [clojure-functions](), [function](), [refactoring](), [test](), [testing]() ### AI overview This Clojure article examines testing a refactoring that replaces stored data with a partially applied function. It explains how to verify the function and arguments using redefinition, while comparing state-based and implementation-focused tests and their maintenance trade-offs. ### Source excerpt I recently refactored some code that takes longs from two different sources to compute one value. The code originally stored the longs and called a function when all of the data arrived. The refactored version partials the data while it's incomplete and executes the partial'd function when all of the data is available. Below is a contrived example of what I'm taking about. Let's pretend we need a function that will allow us to check whether or not another drink would make us legally drunk in New York City. The code below stores the current bac and uses the value when legally-drunk? is called. The following (passing) tests demonstrate that everything works as expected. This code works without issue, but can also be refactored to store a partial'd function instead of the bac value. Why you would want to do such a thing is outside of the scope of this post, so we'll just assume this is a good refactoring. The code below no longer stores the bac value, and instead stores the pure-legally-drunk? function partial'd with the bac value. Two of the three of the tests don't change; however, the test that was verifying the state is now broken. note: The test output has been trimmed and reformatted to avoid horizontal scrolling. In the output you can see that the test is failing as you'd expect, due to the change in what we're storing. What's broken is obvious, but there's not an obvious solution. Assuming you still want this state based test, how do you verify that you've partial'd the right function with the right value? The solution is simple, but a bit tricky. As long as you don't find the redef too magical, the following solution allows you to easily verify the function that's being partial'd as well as the arguments. Those tests all pass, and should provide security that the legally-drunk? and update-bac functions are sufficiently tested. The pure-legally-drunk? function still needs to be tested, but that should be easy since it's a pure function. Would you want this kind ## Why Clojure? Part 2: Effortless async by design DevFeed: [Why Clojure? Part 2: Effortless async by design]() Original publisher: [Read original article]() Published: 2013-04-05T00:00:00Z Content type: opinion Language: en Sources: [Adam Bard]() Topics: [Clojure](), [async](), [Concurrency]() Tags: [agents](), [async](), [asynchronous](), [clojure](), [clojure-functions](), [code](), [design](), [erlang](), [stack-overflow](), [threads]() ### AI overview This second article in a series argues that Clojure makes asynchronous web programming straightforward. It explains using Java threads and closures, futures for deferred results, and Clojure's thread-safe state-sharing mechanisms, including Atoms, Refs, Agents, and Vars. ### Source excerpt As a second part in what I've decided will be a series attempting to justify my choice of Clojure as a general-purpose web language, I'd like to talk a little bit about writing asynchronous code in Clojure, and just how easy the design decisions made by Mr. Hickey make that.