decoding

yes, it’s a common pattern to what Plumatic calls Coercion. See https://www.metosin.fi/blog/high-performance-schemas-in-clojurescript-with-malli-1-2/#transformation for sample code & perf

I have data that looks like this:

"[{:tasks ['path.to.ns.a/foo 'path.to.ns.a/bar 'path.to.ns.a/baz] :other-key :other-value, :etc :etc},
 {:tasks ['path.to.ns.a/foo 'path.to.ns.a/bar 'path.to.ns.b/baz] :other-key :other-value, :etc :etc}]"

(let [data "[{:tasks ['path.to.ns.a/foo 'path.to.ns.a/bar 'path.to.ns.a/baz] :other-key :other-value, :etc :etc}, {:tasks ['path.to.ns.a/foo 'path.to.ns.a/bar 'path.to.ns.b/baz] :other-key :other-value, :etc :etc}]"]
    (->> (clojure.edn/read-string data)
         #_(map :tasks)
         (filter #(some #{'path.to.ns.b/baz} (:tasks %)))))

2 things wrong:

1. edn doesn't support quoting ' -- it is accidental that that doesn't error

(= 'foo (edn/read-string "foo"))

quoting is a clojure code thing

in edn, a symbol is just a symbol, there's no eval to resolve it to something

if you want to eval/resolve a symbol in edn, that's up to you

> edn doesn't support quoting ' -- it is accidental that that doesn't error Oh, I didn't know that, thanks so much for the explanation 🙂. Both result in a symbol, so I assumed it doesn't make a difference (I never had to compare them before).

Do you want the keys to be value{1stElement}, value{2ndElement}, etc?

that seems to be the opposite of destructuring

but (zipmap [:value1 :value2 :value3] [1 2 3])

I would like to be able to specify they key names during the destructuring (for a known number and set of values)

Ahh ok, not familiar with zipmap, will take a peek at that

So while I guess “destructuring” is maybe not the right term, I guess it’s destructure, then “restructure” lol.

destructuring is about binding locals to parts of a value. as soon as you introduce new things (the keys here), you are beyond what destructuring does

but that's ok, we've got lots of library functions to do all that :)

Really what I want is an efficient way to have

{:a [thing] :b [thing] :c [thing]}

But maybe zipmap can do this

well, zipmap constructs a map that way

perfect. Thanks sir for the pointer!

if you haven't found https://clojure.org/api/cheatsheet, you might find it helpful

the built-in constructors are not variadic but seems like you could easily make one around it (even generically if you plumb the defrecord data), depending on what you actually want

the whole idea with records is that there are slots are you are filling them, so variadic constructors doesn't really match great with that. if you want partial / arbitrary order, the map->MyRecord constructor seems like an easy path

Wanting a key that is "optional" but defined as a field, ideally being able to define some default, but still useful if it could just default to nil.

records support arbitrary "extra" keys

so you automatically have optional, nil values of any possible key

(defrecord Foo [a b])
(->Foo :a :b :c)
; => ArityException

(defrecord Foo [a b c])
(->Foo :a :b)
; => ArityException

you can not define :c at all

user=> (defrecord Foo [a b])
user.Foo
user=> (def f (->Foo 1 2))
#'user/f
user=> (keys f)
(:a :b)
user=> (get f :c)
nil
user=> (def f' (assoc f :c 3))
#'user/f'
user=> (keys f')
(:a :b :c)
user=> (get f' :c)
3

records are open, just like any other Clojure map

(but optional stuff is slower to access and you may be just as well off with a regular map if you're using extended records a lot - depends if you need the type)

Got it. But I was asking about a variadic constructor, such that I can include / not include a field on construction. I take it you are saying "No, not possible"?

you can make any function you like :)

but you won't get that automatically with defrecord

thanks

there are some tricks to macro-ize this kind of thing by utilizing some undocumented basis fields in the generated type as that can tell you what fields exist

Wouldn't know where to start on "undocumented basis fields". (I don't even know what a basis field is. 😛)

user=> (Foo/getBasis)
[a b]

it's just the names of the field symbols you created the defrecord with

💡

so you could for example, write a macro that given a type, could emit a function that called the positional constructor that looked at the count of the basis fields and the variadic args you have, pad them and invoke the positional constructor

Thanks. Sounds like overkill for what I'm working on. But I think I need to make an attempt at that, so I don't lose the context of this discussion.

for a known record type, it's pretty easy to write the function:

user=> (defrecord Foo [a b c])
user.Foo
user=> 
(defn v->Foo [& fs] 
  (let [c (count (Foo/getBasis))] 
    (apply ->Foo (take c (concat fs (repeat c nil))))))
#'user/v->Foo
user=> (v->Foo 1)
#user.Foo{:a 1, :b nil, :c nil}
user=> (v->Foo 1 2)
#user.Foo{:a 1, :b 2, :c nil}
user=> (v->Foo 1 2 3)
#user.Foo{:a 1, :b 2, :c 3}
user=> (v->Foo 1 2 3 4)
#user.Foo{:a 1, :b 2, :c 3}

macroizing that is harder, but definitely possible

For posterity, using map->RecordNameinstead of ->RecordName is sufficient for my needs. Better self-documentation of what's actually being assigned at creation, and no need to mention fields initializing as nil.