The answer to your subject line question is: no, s/and applies the first predicate and flows the conformed value (if valid) through any remaining predicates – regardless of where it is used. There’s nothing special about its use inside s/fdef. Per the s/and docstring (emphasis added):
clojure.spec.alpha/and ([& pred-forms]) Macro Takes predicate/spec-forms, e.g. (s/and even? #(< % 42)) Returns a spec that returns the conformed value. Successive conformed values propagate through rest of predicates. clojure.core/and and clojure.spec(.alpha)/and are different functions that do very different things. Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood From: scott stackelhouse Sent: Friday, August 11, 2017 1:06 PM To: Clojure Subject: is s/and different inside an s/fdef? I have to say I find this confusing: "First the :args is a compound spec that describes the function arguments. This spec is invoked with the args in a list, as if they were passed to (apply fn (arg-list)). Because the args are sequential and the args are positional fields, they are almost always described using a regex op, like cat, alt, or *. The second :args predicate takes as input the conformed result of the first predicate and verifies that start < end. The :ret spec indicates the return is also an integer. Finally, the :fn spec checks that the return value is >= start and < end." It really didn't click for me that the second (and I presume subsequent?) predicates of the (s/and) don't get the same argument that the first predicate does. The text does say that, but it runs counter to what a logical AND would mean (commutative property is lost). It also damages the ability to reuse specs in and out of an (s/fdef). It seems to behave more like a (comp) or (->) than a boolean operator now. I can't think of different ways to do it, but I don't think any of them are better. However I can think the example used above this paragraph in the guide could be changed a little to make the behavior clearer... I have never checked, but I assume the clojure docs are on github? If so are pull requests welcomed for updating docs? --Scott -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
