Fork me on GitHub

Is this the proper way to spec a multiple arity function? with :args (s/or ...)

(defn foo
  ([a]    ...)
  ([a b]) ...)

(s/fdef foo
  :args (s/or :arity-one (s/cat :a int?)
              :arity-two (s/cat :a int? :b int?))
  :ret int?)

Alex Miller (Clojure team)13:06:26

I’d use s/alt there instead of s/or as it’s a regex op, but that’s one option

Alex Miller (Clojure team)13:06:47

Another is to push the optionality into the cat with s/?


s/alt is better, thanks


when I run my suite with lein test and I get the generator seed “Using generator seed: -1186346283”, how do I pass that seed into lein test again?

Alex Miller (Clojure team)13:06:38

I don’t know of any way to do that from that level

Alex Miller (Clojure team)13:06:50

stest/check takes an option map where you can pass in a seed

Alex Miller (Clojure team)13:06:57

you might be able to do it through some test.check dynvar or something, not sure


Is there an idiomatic way to associate a doc-string with a spec?


I am trying to generate documentation from spec for non-clojure developers to read. Something like this

(s/def ::id string? "Id of resource X. Ex. resource_1")
(s/def ::num integer? "Number of results for pagination")

(s/def ::result (s/keys :req-un
                        [::id ::num]))

(gen-doc ::result) =>

{:id "resource_1" ;; "Id of resource X. Ex. resource_1"
 :num 10 ;;"Number of results for pagination"

Alex Miller (Clojure team)16:06:20

no, not yet but we intend to add that


@U064X3EF3 Is there any workaround I can do for now? I tried using with-meta but it doesn't with no success since keywords are not Objects. I could however maintain a registry of documentation.

Alex Miller (Clojure team)18:06:15

there are some external libs that are providing this, but it’s hard to recommend those as what they are doing is likely to break

Alex Miller (Clojure team)18:06:39

you could build an external map of spec keyword to doc string


(defonce doc-registry (atom {}))

(defmacro def-w-doc
  [k spec-form doc]
  `(s/def ~'k ~spec-form)
  (swap! doc-registry assoc k doc))

(def-w-doc ::id string? "Id of resource X. Ex. resource_1")


This is what I am using now. This is least intrusive change I could think. Later on when clojure.spec adds support for documenting specs I can just modify def-w-doc.


for the seed, one workflow would be to keep your randomized check, and also do another with a specific seed that creates a known rare corner case


SEED=<seed> lein test is how to do it


oh that works? interesting


I like to have regression tests for things that have been known to fail in the past though

👍 4

(I guess it's better to do that by hard coding the data that had been generated in an example based test)


yup, setting the SEED as an env var works


FWIW, I have never heard of this and have no idea what's going on


my suspicion is it's not a test.check seed, it's something else


I'm curious what others' tastes are regarding namespaced keys in spec definitions? As an example, let's say we're modeling GPS coordinates. Personally, I've been doing something like this:

(s/def :coordinate/latitude double?)
(s/def :coordinate/longitude double?)
(s/def ::coordinate (s/keys :req [:coordinate/latitude
In which lat and long are both "nested" under the :coordinate namespace, and then the coordinate map itself is defined inside of some kind of :my-project.specs top-level namespace (using the ::coordinate sugar). Does this make sense, or are there other conventions that have been established that would be clearer?


@cjsauer That's pretty close to my approach. Much depends on how unique you need the names to be and how your code might be used.


In a library, you'd really want all the names to be globally unique. In an application, you can use less unique names.

👍 8
Alex Miller (Clojure team)18:06:10

they should be sufficiently unique :)


@seancorfield good to hear. This is for an application, so I'll trade some uniqueness for readability 🙂