hmm, this is valid Clojure, but Cursive cannot resolve a:
this is undefined and it’s valid to complain i believe
undefined by clojure or by cursive?
it's valid clojure code, a is whatever you pass in as the first arg to blah
trying to find a recent discussion. But the gist is that the or is not suitable for arbitrary expressions, and certainly not with binding forms in the same destructure
not suitable? This has worked in Clojure since the keys sugar was introduced
i think the distinction is works vs well-defined
the defn -> fn* -> maybe-destructured implementation in clojure core is unambiguous. all params in the arg vector have prior ones in lexical scope
(defn ^{:private true}
maybe-destructured
[params body]
(if (every? symbol? params)
(cons params body)
(loop [params params
new-params (with-meta [] (meta params))
lets []]
(if params
(if (symbol? (first params))
(recur (next params) (conj new-params (first params)) lets)
(let [gparam (gensym "p__")]
(recur (next params) (conj new-params gparam)
(-> lets (conj (first params)) (conj gparam)))))
`(~new-params
(let ~lets
~@body))))))I think it’s defined (undefined would be if a was in same destructuring)
^ makes sense to me it'd be undefined if referring to a different binding in the same destructuring map.
Oh wow, I never realized this is valid Clojure… 🙂 Even this seems to work, but perhaps by accident?
(defn abc [a {:keys [b c] :or {b a c b}}]
(* a b c))
(comment
(abc 3 {}) ;=> 27
)> (undefined would be if a was in same destructuring)
in your :keys [b c] there i think you are touching the stove
yeah… I would probably avoid this kind of {:or { …}} for clarity purposes… in either case
I do use the {:or …} style to provide meaningful defaults but typically they are not related to any other argument of the same fn…
Wasn't there something about this working depending on what backing type is used for the hashmap? Or am I imagining that discussion? 😅
Maps are unordered which is why the order that maps are restructured into bindings is not defined