Thanks Alex. Enjoy the break.

Was wondering, is it possible given two different representations of data to conform to the same thing?

Use case would be for instance taking {:key/id {:some :data}} and turning that into {:key/id id :some :data} given either format.

this seems like a silly question, doesn’t make sense other than having to transform the data after the fact.

I’m unable to figure this out: given example in Rich’s talk if you have a map of email keys and people, how do you spec that? example {”[email protected]" {:person/name “blah” …}}

(s/map-of ::email ::person) I believe

hehe i just found that after failing with s/cat and s/tuple

thanks 😉

Well you can do it with s/every and s/tuple (which is how map-of is implemented)

was there any reason to break the symmetry of symbols always introducing themselves in destructuring syntax by using {:keys [:foo/bar]} instead of {:keys [foo/bar]}?

@olivergeorge I added a comment to your gist with some ideas I've been working on

https://gist.github.com/olivergeorge/85c2b263227676324275ce13408c0fb8 in case anyone else wants to have a look as well

@luxbock isn’t {:keys [:foo/bar]} for aliased namespaces and {:keys [foo/bar]} for unaliased ns? So foo is an alias in the first expression and a full namespace in the second?

No, those mean the same thing

You can use the first with ::foo/bar though for aliased

oh I did misunderstand how it works, I thought {:keys [foo/bar]} would give me foo/bar but just bar works, makes sense

After using spec for a while now and especially heavily the fdefs I just noticed something important for me. What I did up to now, was to spec out the parameter maps for every function extensively. While now I see that it is more practical and enough for me to just spec out endpoints (like database / rest) and spec my functions in a different way for maps. What I do now, is to just add the keys to the spec that I require in that function instead of speccing the whole map. So (s/cat :product ::product-ns/product becomes (s/cat :product (s/keys ::req-un [::product-ns/date-key] Just wanted to share this 🙂

👍

what’s the guidance for spec-ing pseudo-namespaced keywords? i’m thinking like datomic attributes when you do :customer/name or something like that

do you mean “qualified but not referring to an actual namespace” keywords?

yeah

go for it

even when the qualifier is not at all unique?

but if you plan to ever share that code with other people, use adequately unique qualifiers

presumably spec’ing something like :event/type may conflict

yes

yeah - ok so it’s the app vs lib thing

yeah

ok - fair enough

thanks

I just wrote up a side bar for this in Programming Clojure :)

yeah, i could sense that - i’m awesome like that

just helping you test out your advice

well usually people ask about the things I haven’t yet written :)

until you write too much and then everybody decides it is easier to ask you than it is to read the mountain of writings! heh

it’s always simultaneously not enough and too much

damn tradeoffs strike again

i’ve grown tired of writing common :pre and :post conditions and calling s/assert everywhere so i wrote a macro to help me with that 🙂 https://gist.github.com/noprompt/ae3cf5f174a11a61a41e1bdfa96bde28

(example down at the bottom)

it needs just a little more polish but i’ve been happy with it.

i put it to use while implementing the CEK, CESK, and CESK* abstract machines for interpreting the pure lambda calculus and it’s been helpful.

spared my sanity a bit and help catch a few bugs where i was wiring things up incorrectly.

i’m not sure if it’s worth a full blown library or not but i thought i’d share this to show folks something interesting.

where is the code of the pure lambda calculus interpreter?

i’ll gist CEK

side note: implementing /CES?K/ machines is crazy fun

highly recommended to all

@viebel i added it as a comment to the gist.

@bbloom it really is. a co-worker and i have been taking a deep dive in to this stuff. it’s a ton of fun.

i haven’t gotten up to the timestamped or garbage collected implementations yet though.

it’s mostly a matter of reading and converting the math into code.

thx @noprompt. You should write an interactive blog post about CEK stuff:clap:

anyway, the basic premise of the macro is that we often use symbols in function parameters to stand for something and we tend to reuse them in several functions.

the idea here is to specify what those symbols mean and have a macro which handles the business of creating an fdef, instrumenting, etc.

take @bbloom’s GLL parser code for example; he’s got a glossary at the top of one of the namespaces which explains what each of the symbols mean (a good practice btw).

@viebel i might consider doing that during my vacation.

ugh, i just realized i made a mistake specifying ::lam!

@noprompt fun to know somebody is reading that code 🙂

i have some ideas to dramatically simplify and speed it up too - but have to find a few days to work on it

@bbloom i plan to look at it, and the papers, more seriously soon. i implemented a parser combinator library not to long ago and i had to “cheat” in several places to squeeze out more perf.

msg me directly if you wanna chat about it - coding this thing gave me a ton of insights

@bbloom I never heard of CES?K machines, do you have a link I could start with?

matt might’s blog is where to go

he’s got various articles on them

Thanks

I wrote a stateful transducer (I know, I know, it's a variation on a partition theme, so it has to have some state). How do I spec it? I can do it for every arity, but the resulting specs aren't that useful -- I'd better have a spec for the transducing process, not for a single invocation.

@manutter51 https://arxiv.org/pdf/1007.4446.pdf