Fork me on GitHub

i’m trying to get a feel for when it makes sense to use multispec vs or/and/merge/etc.... at first i thought it might be the same tradeoff as with multimethods vs if/case/etc. ie: open vs closed primarily… however i’m not quite sure what the generator behavior will be for and/or/merge w/o the retag function


what’s folks experiences with small/closed alternatives? like say 3 cases where all of them share some “base” fields and each has a couple unique fields


i think in this case i’m looking at now, i can just ignore the “base” notion, but not quite sure


are videos from the clojure-spec workshop at the recent conj up online anywhere?


the datomic workshop videos are incredible, and depending on how my meeting on monday goes, might mean a new enterprise datomic customer!


I started working on a convenience macro for defining a function spec and its definition within the same defn like macro


and I'm trying to decide it it would make more sense to infer the spec of the arguments from the argument destructuring syntax, or to allow you to destructure the output of conform on the input parameters


so an example of the first would be something like [{:keys-req [foo ::a-foo]}] (the argument vector of the function) expanding to (s/cat :thing-with-foo (s/keys :req [::a-foo])) in the :args part of the fdef form


and the second one would look something like [({:keys [xxx yyy]} ::a-foo)] which binds xxx and yyy to be things pulled from (s/conform thing-which-is-a-foo) by wrapping the body of the function definition in a let form that does the destructuring for you


I guess these things are not mutually exclusive, so I could just write two separate macros


both macros expand to (do (fdef ...) (defn ...)) at the top level


maybe I should postpone this until I have more experience with using spec the usual way


I suppose you could even combine them by always grouping bindings and specs in parentheses, so you could do [{:keys-req [({:keys [xxx yyy]} ::a-foo)]}] which defines the :args as (s/cat :arg-a (s/keys :req [::a-foo])) and assuming ::foo is something like (s/cat :xxx int? :yyy int?) then you can refer to xxx and yyy as such inside the function body


if anyone can think of reasons for why this is a bad idea that'd be great so that I won't have to discover this by trying 🙂


@luxbock I would love to see this macro on github when it’s ready


been using update-in, get-in, etc happily for quite some time, but seeing such heavy usage of paths in spec makes me wish Rich would someday give a talk including a rant about xpath/xquery 🙂

Alex Miller (Clojure team)18:12:39

Why would he rant about that?


i don’t know. i would just like to hear his insights/thoughts about it

Alex Miller (Clojure team)18:12:39

I've done a bunch of xquery and I think it's a pretty reasonable functional query language with some good stuff in it

Alex Miller (Clojure team)18:12:54

Not all good of course, but nothing is


yeah, it’s just sorta this forgotten/unloved old good idea to be able to talk about slices of hierarchical data

Alex Miller (Clojure team)18:12:03

So you mean good rants :)


there’s stuff like lens in the haskell world and nathan marz’s specter thing (was that what it’s called?) but rich’s take on these sorts of things is always so lucid


Rich’s recent NYC talk mentions a ‘path system’ in spec. is there some place i can read about this?


i enjoy a solid rant, so i don’t assign the negative connotation by default 😉

Alex Miller (Clojure team)18:12:50

It's just the idea that alternatives or components are tagged

Alex Miller (Clojure team)18:12:56

So you can talk about them


ok, so one could form a path into a conformed structure using those names, got it


as with get-in and friends


@robert-stuttaford it’s not really a “system” so much as it is two things: 1) a vector of keys a la get-in or update-in and 2) makign sure spec gives you good paths whenever you’d need it

Alex Miller (Clojure team)18:12:25

Globally qualified spec name + path together let you talk about any piece


yep, got it — just wanted to check it wasn’t more’n that


how stable is the API now? i took a look in the early alphas, and not since

Alex Miller (Clojure team)18:12:05

Yeah it's used more in the second half of spec


wondering if the water’s warm enough now 🙂

Alex Miller (Clojure team)18:12:24

(That was a joke btw :)

Alex Miller (Clojure team)18:12:37

I'd say the API is pretty stable

Alex Miller (Clojure team)18:12:32

We are unhappy with the details of gen override and instrument options and those might change slightly

Alex Miller (Clojure team)18:12:52

Unhappy with their inconsistency across fns


and i believe you may also be providing exercise with gen overrides


oh, wait, there it is


i’ve got rich’s lisp nyc talk on in the background, that’s why i thought of the xpath thing


i haven’t giving the generator side of spec a serious workout yet - probably should make a concerted effort to try


I’m surprised to see that *print-namespace-maps* is a boolean value and not a number specifying how big of maps to scan in the private lift-ns function


after 1.9 ships i’ll want to add lifted namespace map syntax to fipp, but i want to preserve the linear time and constant space overhead promises


surprised to see no such guarantee in the default clojure repl - but then i guess printing large values is sorta bad interactively anyway


Is it intentional that there are no bigint? and biginteger? predicates + corresponding generators?


might have to do with cross-platform issues


@gfredericks Hmm possibly... there is bigdec?, though


Yeah I dunno. Can write your own though.

Alex Miller (Clojure team)21:12:00

I think it was just an oversight and I might even have a ticket for it

Alex Miller (Clojure team)23:12:53

right! has some issues. Feel free to work on a patch! :)


I could probably do it


@alexmiller adding the generator in test.check could work too, right?


I guess it could start in clojure.spec and get pulled out if the timing works; users wouldn't need to care