how to make spec for list of maps? '({}{}{}) ?

(s/coll-of map?)

but most of the time you want something more precise than map?

but how to make that the maps also conforms to a spec?

replace map? with a namespaced keyword that points to a spec

or a spec directly

Any reason why (s/explain-data a-spec a-value) does exactly what is expected (and is correct) and given the exact same input (s/valid? a-spec a-value) fails with a class cast exception? This is on 1.9

do you have the spec and example data? did you test in clj 1.10?

@jsa-aerial https://dev.clojure.org/jira/browse/CLJ-2372 maybe?

@favila doesn't look to be that (might be peripherally related). I think the issue is related to a misuse of s/merge in my case. I have a set of predicates def'd to specs. None of these are map/key related (like with s/keys) so none involve a map. Then I use s/merge (because s/and short circuits...) on these. Now, s/merge is happy to do this. s/explain-data is happy to do 'the right thing' and check all predicates of the merged spec. But s/valid? has a bug as well, but instead of 'doing the right thing' it just blows up. I put 'right thing' in quotes because I suppose s/merge should not allow this in the first place. All of this is a shame - s/and should not be short circuiting in the first place. This is a logic system after all. If you are concerned about guarding flow through to other predicates then your predicates are what's broken. I suppose you could have a guard operator for that sort of case, but IMO, that would still be bogus. ¯\(ツ)/¯

why would you want s/and not to short-circuit?

Because you are saying that the spec should satisfy all predicates. Like in propositional logic. Not programming languages

The reason this is really useful is because you would like to catch all the errors in one go - not get one report to user. fix that one, get the next, report to user, etc. That is really annoying and just wrong

but s/and accepts specs and conformers

not just predicates

well, nm just conforming is a problem

so you would have to drop conformers, or introduce some trickery about evaluation

even if all were evaluated order would still have to matter

@jsa-aerial s/and flows data through all the specs so it must be short-circuiting -- it has an inherent order and you can't rely on being able to apply subsequent specs if an earlier spec fails. (and I feel we've had this conversation before)

Yeah, each next spec in s/and receives conformed value from prior one. So if one step is invalid – next would just blow up with random noise instead of useful explain data.

otherwise how would you s/conform to s/and spec? conform only last step? none? Most of the s/and specs I saw – check fields first, and then some relation between them next (e.g. this id and that id are the same.), which is basically: 1st step is conforming, last is not

if s/and were restricted to predicates, and predicates were written defensively (which they should be IMO), then I think what @jsa-aerial proposes would be fine; order could be used for making generators, but all could be checked in parallel

how do you restrict to predicates only?

I mean if conformers were not legal

bascially, you would have to drop conformers as a feature of s/and

well, this excludes s/keys

or anything containing s/or

I don't follow?

I'm just talking about s/and. Maybe for clarity I should say this would not be s/and anymore. s/nonconforming-and or s/parallel-and

s/all maybe

I'd call it s/every or something. But "flowing" behavior was surprising to me back then, I agree

but, how would such s/every be more useful than clojure.core/and?

every predicate would be tested unconditionally

I should say, could be

is this for form validation or something?

I'm guessing

ok, clojure.core/every-pred

something user-facing

but I haven't found spec very useful for things like that

what extra would it provide?

report all errors instead of just the first one

maybe build your tool on top of spec, but not use s/and to collect all the errors. just call s/explain for each field for example

you can't exercise it, can you? because it involves conforming

conforming and excercising seem orthogonal?

exercise gives you pairs of [generated conformed], I think?

the conformed of s/every would always be identity

or whatever, s/every-pred

I think you'll be able to implement such s/every on top of spec2

no conforming

I'm more curious what the explain-data would look like

ok, what if one of the items in s/every would be spec with s/and inside? it'll propagate conformed value, I think

It's worth pointing out that Spec2 draws a harder line between specs and predicates -- and s/and accepts specs, not arbitrary predicates. See https://github.com/clojure/spec-alpha2/wiki/Differences-from-spec.alpha

the point is, this spec would simply not do that

well yeah, explain - "conforms"

(! 591)-> clj
Clojure 1.10.0
user=> (require '[clojure.spec.alpha :as s])
nil
user=> (s/def ::foo (s/and int? (partial > 10)))
:user/foo
user=> (s/valid? ::foo 10)
false
user=> (s/valid? ::foo 1)
true
user=> ^D

Tue Feb 26 11:22:41
(sean)-(jobs:0)-(~/clojure)
(! 592)-> clj -A:spec2
Clojure 1.10.0
user=> (require '[clojure.spec-alpha2 :as s])
nil
user=> (s/def ::foo (s/and int? (partial > 10)))
:user/foo
user=> (s/valid? ::foo 10)
Execution error (IllegalArgumentException) at clojure.spec-alpha2/spec* (spec_alpha2.clj:197).
No method in multimethod 'create-spec' for dispatch value: clojure.core/partial
user=> 

@seancorfield I don't see "not arbitrary predicates" there. It says "Qualified symbols (predicate function references)" are ok

@misha See the code I just posted above.

what if you defn it first, instead of partial?

probably it needs an fspec

(just guessing)

which sounds great to me

(s/def ::foo (s/and #(int? %) #(> 10 %)))

I think it should be orthogonal: fdef and predicate fn

Yes, you can def a predicate from (partial > 10) and then it falls into the set of things that can be treated as a symbol spec. But the point I'm making is that s/and isn't intended to operate on predicates, it's for specs.

in spec2? or in both 1 and 2?

We got our entire codebase up and running on Spec2 and we had several places where we had "mixed" specs and predicates and those were rejected and we had to rewrite things somewhat.

so a def-ed predicate is a spec

most of my use cases for s/and were s/keys + fn

well symbolic spec, not spec object

@favila see above. anonymous functions are allowed, but you have to write them with fn or #(… %)

that doesn't jive with the doc @seancorfield linked

To be honest, I found it confusing too, but that’s how it works now

also, my impression was, that any predicate is sort of first class in spec by design

It's an important (but subtle) distinction. Spec1 doesn't enforce it but Spec2 does.

what about michiel's counter-example?

What counter-example?

(fn [x] int?) is a “symbolic spec”, it’s just what they call it now

"fn" is a spec form?

but just simple symbol isn’t, like int?

I see how spec2 could disallow fns returning fns as predicates (partial), but forbidding anonymous fns would be strange (and doing it only for few spec forms – just awkward)

I think this will be a source of much confusion.

int? is acceptable as a symbolic spec.

> Spec forms (lists/seqs), with spec op in function position, composed of other symbolic specs > Qualified keywords (names that can be looked up in the registry) > Qualified symbols (predicate function references) > Sets of constant values (an enumeration)

unless "fn" is a spec form, I don't see how anonymous inline fns would be allowed

even then that seems iffy

@jsa-aerial s/merge is for "map-validating specs", it's not for things like "also check that value in [:foo :bar] is the same as in [:baz]" but s/and - is exactly for that

Yes, I know that - just saying it does satisfy all semantics

which "all semantics"?

He means "not short-circuiting"

If you merge a bunch of specs it check them all

I meant, it is (s/and keys-spec custom-pred) or (s/and regex-spec custom-pred)

keys-spec could be (s/merge keys-spec1 keys-spec2 ...), yes. but important part is a custom-pred, which is usually (for me) goes last, and does not conform anything, but often requires conformed input, in case there are branches with different "postvalidation" semantics required

a new guide on coercion with spec1 and spec-tools: https://cljdoc.org/d/metosin/spec-tools/0.9.0/doc/spec-coercion