I feel like I’m possibly using these control flow macros in a way that makes the intent unclear or hard to follow

You can definitely simplify wrap-auth-session and avoid that nesting:

(if-let [user (some-> (get-in request [:cookies "sid" :value])
                      (get-active-session)
                      :user_id 
                      (get-user-by-id))]
  (handler (assoc request :user user))
  (handler request))

You can remove the (do ..) wrapper in the first function -- you only have one expression in there so it's unnecessary to wrap in do. I don't think you can do much other simplification -- parameter access / validation in Ring handlers is always a bit verbose.

Not sure what you mean by "control flow macros" tho'...?

Thanks for the tips! I think some-> is perfect for what I was trying to achieve there. By control flow macros, I only meant things like do , if-let, if, and so on. Wasn’t sure what else to call them

They're special forms, technically, but we tend to just refer to them directly by their names. See https://clojure.org/reference/special_forms When you say "macro" it has a very particular meaning in Clojure.

(and, yes, it's a little blurred that a couple of the special forms are actually implemented as macros that expand to lower-level implementations: let in terms of let*, fn in terms of fn*)

I got it 🙂

actually no I don’t

Are you looking for something like this:

user=> (match [['a ['b 1 2 3]]]
[[_ [_ & r]]] r)
[1 2 3]
user=>

Or if you really want sequential matching

user=> (let [x '(a (b 1 2 3))]
         (match [x]
           [([_ ([_ & r] :seq)] :seq)] r))
(1 2 3)
user=>

(I'm a bit puzzled by your ('a ('b 1 2 3)) example since that is not what you might think:

user=> ('a ('b 1 2 3))
Execution error (ArityException) at user/eval1600 (REPL:1).
Wrong number of args (3) passed to: clojure.lang.Symbol
user=>

^ @U015GL869TQ is that helpful

yes! thank you! I ended up doing what your showed in your second example

and yes I should have written '(a (b 1 2 3))

macros receive lists and symbols, unevaluated

whatever the macro returns will be evaluated afterward

lists will become calls, symbols will be looked up - after the macro returns them

the only job of a macro is to take lists, symbols, etc, return a list (or rarely, just a symbol or whatever), so that the compiler can do the rest

'fn-name shows up to a macro as (quote fn-name) because the args are not evaluated before the macro sees them

the args to the macro don't expand in the context of the macro definition, they always expand in the context of the macro call

but, the macro can't see the run time value of a symbol - it can return the symbol, and the compiler turns that into code that looks up the value at run time

this isn't a good macro, but it establishes a point:

(ins)user=> (defmacro caller-x [] 'x)
#'user/caller-x
(ins)user=> (let [x 0] (caller-x))
0

by returning the symbol x, it causes the compiler to emit code that looks up x

@UAB2NMK25 , on that topic, i would recommend https://youtu.be/ROor6_NGIWU

the gist is to replace state with flow between simple machines. the talk had a lot to say about how this looks in the “large” (between multiple programs and servers), but also in the “small” (within programs)

I think I watched that before but I will watch it again.

https://www.infoq.com/presentations/clojure-core-async/ is similar, but i usually don’t recommend it since clojure.core.async is usually overkill for most projects

but the principles are still useful even if you don’t use the library

Here is a simple toy I built that I ended up using as the basis of my app so you can see what I mean about addicted to state. https://github.com/michaelwhitford/clojure-swapi

a vector is a form - everything the clojure repl can consume as a standalone value is a form