I’m trying to understand the difference between s/coll-of and s/every. > Note that 'every' does not do exhaustive checking, rather it samples coll-check-limit elements. Nor (as a result) does it do any conforming of elements. 'explain' will report at most coll-error-limit problems. Thus 'every' should be suitable for potentially large collections.

What does it mean that every doesn’t do any conforming of elements?

(s/conform (s/every number?) (range 1000)) seems to do the conforming pretty well!

@viebel Try with a spec that conforms to a different value

Like s/or

Like this:

(s/conform (s/every (s/or :n number?
                          :s string?))
           (concat (range 1000)))

Yeah that should work

If I understand correctly s/every leaves the data as-is

Yup!

while s/coll-of conforms it

It will only check whether the values match the spec

Right

Thx @dergutemoritz

YW!

I cannot find the correct way to call clojure.spec.test/check on my function that might read a file `

(s/def :read/file #(instance? File %))
(s/def :read/content string?)
(s/def :read/fail nil?)

(defn read-file [^File f] (when (.isFile f) (slurp f)))

(s/fdef read-file
  :args (s/cat :f :read/file)
  :ret (s/or :read/content :read/fail)
  :fn (fn [{{f :f} :args ret :ret}]
        (if (.isFile f)
          (s/valid? :read/content ret)
          (s/valid? :read/fail ret))))

(defn gen-file []
  (gen/elements (map (fn [^String f] (File. f))
                     ["./project.clj" "foo"])))

(s/exercise :read/file 4 {:read/file gen-file}) 

I’m reading (with enthusiasm) "CREATING A SPEC FOR DESTRUCTURING” http://blog.cognitect.com/blog/2017/1/3/spec-destructuring. Everything is pretty clear except one point related to s/merge at the end of the article

;; collection of tuple forms
(s/def ::map-bindings
  (s/every (s/or :mb ::map-binding
                 :nsk ::ns-keys
                 :msb (s/tuple #{:as :or :keys :syms :strs} any?)) :into {}))

(s/def ::map-binding-form (s/merge ::map-bindings ::map-special-binding))

I don’t understand why inside ::map-bindings, we have the :msb part

AFAIU, the :msb part relates only to ::map-special-binding

any idea @dergutemoritz or @alexmiller ?

@viebel It makes sure that no other keywords than the ones in the set are present

::map-special-bindings is defined in terms of s/keys which is an open key set by design

At least that's what I surmise is the motivation. Being the author of that post, @alexmiller might have more insight 🙂

That makes sense. But I think it would be clearer if (s/tuple #{:as :or :keys :syms :strs} any?) was part of ::map-special-binding. What do u think @dergutemoritz ?

Not sure I would find it clearer that way

The way it is now makes the ::map-special-bindings spec a tad more widely usable I guess

ok. makes sense

making ::make-special-bindings reusable is not really a goal

the tuple check can’t be part of ::map-special-binding b/c that spec is a map spec which is merged with the rest

I think it’s probably a reasonable criticism that this spec is too restrictive (from a future-looking point of view) in narrowing to just this set of options as we know it now.

the intention is really to segment the space of possible tuple forms to bindings (which are simple symbols, vectors, or maps), qualified keywords whose names are “keys” or “syms”, or special options. Here I’ve listed a concrete set of options but lost the open-ness of something like keys. That could be addressed by replacing the #{:as …} with something more generic like simple-keyword?.

^^ @viebel @dergutemoritz

that makes some sense to me ^^ another option would be to use conformers to rewrite the :as in to a ::as node, so that it’s value can be properly checked to be a simple-symbol, for example

that seems like the the way to recover the openness with all the benefits of the global namespaced keys validation

@alexmiller I don’t understand why in this case, the open-ness is desirable. I mean if someone passes :wrong-keys (instead of :keys) to a let statement, it should be invalidated...

@bbloom no desire to use conformers for something like this

@viebel the same reason openness is desirable elsewhere (see Rich’s keynote from the conj)

that is, if you specify a constraint, then removing the constraint later is a breaking change, not an additive change

@viebel just to make up some straw man extension, consider if you wanted to add some metadata to the match

{:keys [x y] :types {x int}} ;-)

you don’t want the spec to reject that types

@alexmiller sorry, i was thinking about :as in vectors - i think conformers make sense there

for maps, it’s already a map 😛

the :msb form is interesting tho - why not just use a :req-un for the :as key?

i must be missing some subtlety

oooh, you also do that, this is about accumulating extra information in the parse - ok, i think that makes sense.... sorry for thinking aloud here

yes

this is a particularly tricky instance of what has been called a hybrid map

which has both a k/v spec + a keys-type spec

the tricky part being the :<ns>/keys and :<ns>/syms which are like keys but only semi-fixed

yeah, my experience w/ hybrid maps has been that they are more trouble than they are worth except for very limited syntax use cases

nonetheless, they exist :)

indeed

i’ve run in to the ::keys bug

yeah

it is not obvious what to do about that 🙂 so i just renamed my thing, heh

well, I have some ideas about that but haven’t had a chance to put a patch on there

but basically it needs to not use s/keys

as that has behavior that we don’t want in this particular case

namely, matching all keys as specs

yeah, i think the patch i saw there was like a flag to disable the nice open validation of keys - which seems like the wrong way to go about it. easier to factor out the parts you want and then call the underlying part directly

ie composition over parameterization

that patch is dead, not doing that

i assumed that 🙂

and I think I rewrote the ticket to remove that as an option

cool - i have only been following at a distance

it seems like you can't use spec to spec a map like {::results ... ::type ...} where the value associated with the key ::type determines what spec is used against the value associated with the ::results key

it seems like the best you could do would be something with multi-spec, with a different ::results spec (registered under a different key) for each possible value of ::type

I am trying to spec what I have been thinking of as a result set, a map with a structure like {::results [...] ::next ...} where ::next is used for pagination, and the items under ::results will vary with the query that was run. my first thought was to slap a type tag on the result set, and use a multi-spec, but that doesn't work.

hiredman: we’ve talked about context sensitivity a bunch of times here in the past - you have a number of options

none of them particularly great

the simplest one is to just call the spec you want yourself

too opaque

well it depends on your use case

yeah, for mine it is too opaque 🙂

heh, ok

i mean, it’s just an s/conform call

I think I will just have a bunch of slightly different specs, remove any kind of polymorphism

yeah, so that’s the next simplest solution

for now, or until something better comes up

one key for each possible type and then use multi-spec

so you have like ::foo-results and ::bar-results

I am generating documentation and json schema from these specs

yeah

well, easiest, since consumers consume json, is to differ based on namespace, which just disappears in the json encoding

heh, well i guess that works 😛

what about something like

(require '[clojure.spec :as s])

(s/def ::type keyword?)
(s/def ::value any?)

(defmulti t-val identity)
(defmethod t-val :a [_] int?)
(defmethod t-val :b [_] string?)

(s/def ::tagged (s/and (s/keys ::type ::value)
                       #((t-val (::type %)) (::value %))))

(def foo {::type :a ::value 1})
(def bar {::type :b ::value "2"})
(def baz {::type :b ::value 1})

(s/valid? ::tagged foo) ;-> true
(s/valid? ::tagged bar) ;-> true
(s/valid? ::tagged baz) ;-> false

once you start building using functions instead of the combinators (like s/keys) explain is less useful, and any kind of treatment of specs as data becomes more of pain (like if you are walking them to generate something else)