This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-04-27
Channels
- # architecture (6)
- # beginners (36)
- # boot (4)
- # cider (74)
- # cljsrn (5)
- # clojure (87)
- # clojure-denver (2)
- # clojure-finland (2)
- # clojure-gamedev (5)
- # clojure-italy (10)
- # clojure-nl (1)
- # clojure-uk (45)
- # clojurescript (33)
- # code-reviews (5)
- # core-async (12)
- # cursive (17)
- # datascript (2)
- # datomic (71)
- # duct (4)
- # emacs (19)
- # figwheel (1)
- # fulcro (4)
- # garden (1)
- # hoplon (18)
- # jobs (5)
- # leiningen (2)
- # off-topic (73)
- # onyx (14)
- # overtone (2)
- # portkey (32)
- # re-frame (62)
- # reagent (46)
- # shadow-cljs (76)
- # spacemacs (2)
- # sql (14)
- # tools-deps (5)
- # yada (3)
I just figured out something interesting and wanted to share it. Suppose you have a threading macro variant that accepts multiple inputs. Let’s suppose you have when->
in your toolbox.:
(-> 123
(when-> number? inc)
str)
; => "124"
(-> :x
(when-> number? inc)
str)
; => ":x"
Now suppose you want to rewire the inputs and output of when->
to specific arbitrary values. How would you write this ?
(-> 123
(when-> (<- *option*)
inc)
str)
(-> 123
(when-> number? (<- "number"))
(when-> keyword? name)
...)
Here is how I wrote <-
:
(defmacro <- [& body]
`((fn [& _#] ~@body)))
cond->
doesn’t handle threading the value to test forms
We have condp->
and condp->>
macros at work that thread through both the predicate and the expression. I suspect it's a fairly common pattern.
I wrote a macro to define ->
and ->>
variants in one shot. With a few examples: