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 🙂

Why would he rant about that?

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

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

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

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 😉

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

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

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

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

wondering if the water’s warm enough now 🙂

(That was a joke btw :)

I'd say the API is pretty stable

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

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.

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

Oh yeah: http://dev.clojure.org/jira/browse/CLJ-1951

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

Yup