Fork me on GitHub

tuple is not a parameterized coll (see coll-of for that), (tuple number?) says vector of exactly one number


tuple is for short tuples of heterogeneous types each of which will be listed


@richhickey Oh hi! My comment is about the message, not that it should pass…


e.g. (tuple string? number?)


I was saying that it reveals implementation detail of spec/tuple.


I was reading the rationale document as saying that we want to capture the predicates the user supplied, so I was hoping for something like: val: [] fails spec: (tuple number?).


that doesn’t tell you much


Hrmm, this is true.


and the interior preds can be arbitrarily complex, will walk down


much better than “you failed the top"


Hrmm. So my (clearly not thought through) expectation would be that count would fail at tuple, but sub-types would fail more specifically. That’s not an idea I can make coherent, though.


(Anyhoo, super excited about clojure.spec’s new ideas, cf prismatic)


is it possible create a spec for a map like {[300 200 54] :status/open} e.g. map keyed by vector of integers


@shaunxcode yes I believe so using map-of


(s/map-of (s/coll-of integer? []) #{:status/open})


@kovasb: Sure, sounds doable


Should I include test.check as an explicit dependency when using spec? I got: FileNotFoundException Could not locate clojure/test/check/generators__init.class or clojure/test/check/generators.clj on classpath. clojure.lang.RT.load (


when instrumenting the adder example from the guide (cc @alexmiller )


@borkdude: Yes, you need it for most cases if you want to use spec in your tests. There was only one function that works without test.check (I think it was spec/gen, but not sure). I have read it somewhere in the official docs in the last days.


Anyone else got an idea why this snippet fails?


@anmonteiro: wrapping it in (s/spec... doesnt fix it unfortunately


Also, what works is:

(s/conform ::columns [{:foo "some_t"}])
=> {:col [{:foo "some_t"}]}
which is strange, cause all I do next is to put it into the argument definition of my function


Can someone reproduce this?


Is there space in spec, for a specification to take parameters via lexical scope? This may be out of scope for spec. For example, on http request, I take a snapshot of my database, and I want to check if a value is in that database. But I want to have my predicates registered via s/def so that I can take advantage of :via and such. Use case is checking if an email is taken during user registration.


Library authors might want to add specs to their existing projects but also keep supporting earlier versions of Clojure


Is this a use case that has been thought about, or isn’t there any interest in supporting such use case?


or are we just supposed to solve it through versioning?

Alex Miller (Clojure team)12:05:40

Specs could be provided in an adjunct library too

Alex Miller (Clojure team)12:05:42

Ultimately, things must move forward to get the benefits of new features as we did with records, protocols, transducers, reader conditionals, etc etc


Agreed wrt. 2nd point


and yea, the optional library add-on could also be a possibility for initial compatibility, hadn’t thought about that


@anmonteiro: having spec in both clojure.core + an external library could cause namespace conflicts

Alex Miller (Clojure team)12:05:29

They can also be in a separate namespace in your library jar that's just not loaded (unless you're on 1.9)


@bronsa: I understand, but I didn’t mean that.

Alex Miller (Clojure team)14:05:29

1.9.0-alpha3 is now out with several bug fixes and improvements for spec!topic/clojure/WxT9kPIwlYI

Alex Miller (Clojure team)14:05:04

The guide is now out of date but I will have it updated shortly


@alexmiller: Is there much of a story for what I mentioned previously? Trying to decide how to approach the problem of generating/validating forms.

Alex Miller (Clojure team)15:05:45

@dominicm: you could register (at runtime) an s/def that partialed/closed-over something known at runtime like a database snapshot. This implies that you are using spec to do runtime data validation. Whether or not this is a good idea, I'm not sure. :)


@alexmiller: Yeah, I did wonder if dynamic vars might be a solution, and a bad idea. I'm definitely thinking in the domain of variable user-input, as opposed to contracts during development. I like the idea of spec as a ubiquitous format that the clojure community uses to describe data. Some data just can't be controlled (user input). Maybe this is way out of scope for spec though, and you guys think that should be a different library altogether. There's definitely a lot of overlap in that space (email still needs to be a string, over 5 chars, match a regex, before it is db checked). Nothing says a validation library can't register things for you of course. But I try to keep core at the top, not other libraries.


The registry itself is pretty simple, I think a 3rd-party lib could sub out the behavior you want but use registered specs along the way.


@gtrak: Yeah, that's what I was thinking about. But if it is in scope for spec, that would be pretty cool.


my understanding so far is that spec itself is mostly concerned with the lib-sharing/transmission/self-describing-edn use-cases, but there are a lot of developer-convenience type cases we'd also want to use it for (overlap with Schema), but it can't integrate all of them.


For instance, the first thing I wrote was a multimethod type->spec coercer, which is a special case extension of the built 'conform', I wouldn't expect that to get into clojure.spec, but I might expect it to be available as a lib, since it's so easy to write.




usage: (s/def ::my-key-that-only-matters-to-my-app (coercer integer?))


the one thing I'd request from clojure.spec itself was a way to provide a better error message than what s/conformer creates, which in this case is too generic, a failure in the pred: (fn [from] (coerce from to)). It's possible I can do so by dropping down a level in abstraction but haven't gotten that far.


@gtrak: oh I agree! I had wondered if that would be possible! Shame you beat me to it. But I feel like being unable to lexically scope a spec in some way hinders me a little. Maybe I'm looking at it wrong, or maybe I can come up with a clever roundabout way to do it and lib it up.


I think I overheard that specs are serializable somewhere, so lexical scope could really mess that up.


I probably shouldn't refer to scope. What I want is a solution to the problem of runtime values effecting the running of my predicates, without relying on state. Am I making sense?


I don't see how it's possible to do that without state, maybe a dynamic/threadlocal registry, but then the state's in the registry.


or you create a one-off spec every time


or every consumer of the registry has to let you tunnel things into specs


@alexmiller: I just found a possible bug in the following snippet:


Running lein test for this code will run into a never ending loop when it tries to test leiningen.s-play-test


I would expect an error message here


The cause is this line (s/fdef foo :args (s/cat)) with the incomplete (s/cat) expression.

Alex Miller (Clojure team)21:05:50

Feel free to file a jira for it