hmm bear with me as i try to understand this. if we have a couple of invariants like: 1. we don't break APIs in non-alpha software and 2. if we do break an API, we pick a new name and 3. clojure.core (non-alpha) will depend on clojure.spec.alpha, then doesn't this imply that for a version of clojure to depend on a clojure.spec (and NOT depend on clojure.spec.alpha), it will have to change its namespace, say to something like clojure2.core? or have i missed something obvious?

clojure.core doesn't depend on clojure.spec.alpha

thanks @alexmiller although I'm more confused now than before. i misinterpreted your comment above about the circular dependency. perhaps i should just go look at the artifacts 🙂

hmm, @alexmiller could you elaborate a bit more? I'm just not understanding how to reconcile that with your previous explanation that "clojure will have a compile-time dependency on spec.alpha so you can always rely on it being available. So you don’t need to explicitly list the new library as a dependency." sorry if i'm just being a dunderhead...

my original statements are about artifacts. yours seemed to be about namespaces, so I answered in those terms. can you clarify which level you’re talking about?

Clojure 1.9 will ship with an alpha version of spec available - use it if you like (but beware that things in spec may change)

that’s the whole story

Is there a natural way to have the generator for a regular expression spec return a vector instead of a sequence?

currently, no

but it is something many people (including myself) have felt the need for and something I have discussed a couple times with Rich

and I think ultimately something will plug that gap

Ok, thanks. (The two use cases I have in mind are hiccup forms and function argslists)

yes, I’ve run into it in spec’ing the latter

@alexmiller oh i see so you'll declare a dep on the artifact but never require it is that right?

mostly - there are a couple things in Clojure that use spec

one is the args check for fdef macro specs during macroexpansion (so in the compiler)

the other is the lookup and inclusion of specs in printed docs from clojure.repl/doc

both of those are kind of implicit rather than being part of the API though

ok thanks, that gives me much more to chew on. 🙂 i don't see this necessarily impacting me, i just really want to grok the engineering you're doing 🙂

So in the meantime, something like this should be ok (to return vectors from a regular expression): https://gist.github.com/mhuebert/8fdeedae57bf797778054dcf8f33ab8b

gen/fmap with vec would be simpler, no need for bind here

#(gen/fmap vec (s/gen expr))