Fork me on GitHub
Oliver George00:12:25

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 😉

Alex Miller (Clojure team)03:12:22

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


@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?

Alex Miller (Clojure team)13:12:54

No, those mean the same thing

Alex Miller (Clojure team)13:12:36

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

Alex Miller (Clojure team)18:12:14

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


even when the qualifier is not at all unique?

Alex Miller (Clojure team)18:12:49

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


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


ok - fair enough

Alex Miller (Clojure team)18:12:19

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

Alex Miller (Clojure team)18:12:04

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

Alex Miller (Clojure team)18:12:55

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 🙂


(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.

Yehonathan Sharvit19:12:47

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.

Yehonathan Sharvit20:12:53

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


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.