The URL in the sticky note of this channel seems broken : http://clojure.github.io/clojure/branch-master/clojure.spec-api.html

The correct URL may be https://clojure.github.io/spec.alpha/ ?

Yes, that last url is the correct one. Earlier, spec was in clojure and the prior one was correct

beginner question: Can we use spec to validate the correlation between values at different places in a structure?

yes, are you thinking maps or another type of structure?

For example, if I want to write a spec for [a b 1 5 ... 3 a b] where a and b could be anything.

... supposing that the structure is complex enough so that I would need to use s/conform to match the location of a and b at different places.

I could use a classical function to check if they match at different places, but I would like to know if there is a better spec-ish way to do it. Something like declaratively defining the pattern.

For example, something like: "For any a, b : [a b ... a b] is valid."

something like this?

(s/def ::my-coll
  (s/* (s/alt :a-b (s/cat :a #{'a} :b #{'b})
              :num number?)))
(s/conform ::my-coll ['a 'b 1 2 3 'a 'b])

Is there a way to manually conform function arguments before I call (apply myfn args)? I.e. having

(spec/fdef myfn :args (spec/cat :userid ::userid))

make a separate spec of the :args and use s/valid? on it ?

you can then write (s/fdef myfn :args ::foo-args ... )

wondering: why wasn't check-asserts based on a dynamic var like *compile-asserts*? Right now it's a bit all or northing at runtime for assertion checking (for the one that are compiled at least)

it's easy enough to work around it anyway

all or nothing is kind of the typical modes for assertions

you can also grab the :args spec of a spec’ed function with

(-> `myfn s/get-spec :args)

I'm wondering if I can do any better if I want to have two different specs for the same key... I have a generic auth-provider , e.g. #:auth-provider{:type "ldap" :config {:host "abc" ...}} This has a generic spec :

(s/def :auth-provider/config (s/map-of keyword? any?))
...
(s/def ::auth-provider-spec (s/keys :req [:auth-provider/type
:auth-provider/active?]
:opt [:auth-provider/id
:auth-provider/default-role
:auth-provider/config
:auth-provider/priority-order
:auth-provider/role-mapping]))

(s/def ::ldap-provider-spec (s/and
::auth-specs/auth-provider-spec
;; this is less descriptive than using `s/keys` directly
;; but we cannot use `s/keys` because `:auth-provider/config` default
;; spec is already registered in auth-specs namespace
;; and you cannot have two different specs for the same namespaced key
#(s/valid? ::ldap-config (:auth-provider/config %))))

look again at multi-spec, @jumar. it would be verbose solution, but sounds like it fits.

although, it'd be much easier, if you'd put :auth-provider/type inside config itself

if you put type inside config itself - multispecs will be about config keys, net provider's ones

or you can just s/or the :provider/config, but it will not keep :provider/type and or's branches "in sync"

how do you guys spec a map where keys are generic and values are constant for a type? To give you an example, clojure.xml will output something like {:tag :first_name, :attrs nil, :content ["John"]}. How would I spec that I want my ::first-name to have this structure? The keys function would require me to make a spec for ::tag but the value is constant for ::first-name and at the same time, different in another spec, I can't globally specify ::tag spec.

@roklenarcic I suspect you'll want a multi-spec for the various types of parsed maps you can get back from clojure.xml

(and the multi-spec would branch on the :tag key's value)

I'll look into it.

There's something weird with the large-integer generator. As is, it never generates a number over a 100. Even if I use the large-integer* generator with options, the numbers are very low.

(gen/sample (gen/large-integer* {:min 1 :max 1000000}))
=> (2 2 1 4 1 1 9 1 2 15)

The test.check generator clojure doc states:

(def ^{:added "0.9.0"} large-integer
  "Generates a platform-native integer from the full available range
  (in clj, 64-bit Longs, and in cljs, numbers between -(2^53 - 1) and
  (2^53 - 1)).
  Use large-integer* for more control."
  (large-integer* {}))

try generating a larger sample

(gen/sample (gen/large-integer* {:min 1 :max 1000000}) 1000)

hm... I guess I expected that generated numbers were uniformly distributed and so it would be extremely likely that a number over a 1000 was generated in 10 tries

@roklenarcic the large-integer generator exhibits growth just like most of the other generators

meaning it respects the size parameter

gen/sample with 1 arg gives you samples using sizes 0⇒9

I see, thank you

The reason I was worried is that when I use integer generator to generate ids, I get a lot of non-unique small numbers (because of the small initial range), which makes it very likely for a sequence of generated entities to have non-unique IDs, which causes such-that to fail occasionally, when IDs are specced to be unique.