RE: is s/and different inside an s/fdef?
Sean Corfield
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 clo...@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+u...@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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
scott stackelhouse
I had't realized this was the case. I was fooled by the fact that conformed values often are the same as the unconformed value. That changed in the fdef where the the arg is enclosed in a seq. My spec setup didn't work as is, but the work around (s/cat :arg ::my spec) as the first predicate in the s/and worked.
--Scott