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 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.

Re: is s/and different inside an s/fdef?

[scott stackelhouse]

sorry, I edited this a few times and bumbled the words.  That last sentence 
should say:  I can think of different ways to do it, but I don't think any 
of them are better.  However I feel the example used above [...]

On Friday, August 11, 2017 at 1:06:39 PM UTC-7, scott stackelhouse wrote:
>
> 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.

is s/and different inside an s/fdef?

[scott stackelhouse]

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.

RE: Converting json to work with clojure.spec

[Sean Corfield]

> However this doesn't produce good results if your JSON contains a key you 
> haven't listed in fields –
> so you'd probably have to write an actual function to do the mapping.

(def my-ns *ns*) ; bind at compile time
;; or use a constant string for the ns if you want
(defn fields [k] (keyword (str my-ns) k))

(fields “name”)
;;=> :chtst.core/name

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: Peter Hull
Sent: Monday, August 7, 2017 1:04 AM
To: Clojure
Subject: Re: Converting json to work with clojure.spec


On Sunday, 4 December 2016 15:11:55 UTC, Jonathon McKitrick wrote:
That being said, I see the benefits in moving to namespace qualified keys. 
Currently, I'm returning structures directly in Compojure handlers, and the 
JSON conversion is implicitly handled. I checked Cheshire and didn't 
immediately see a way to generate namespaced keys. What's the best way to do 
this?
parse-string takes a second argument that converts from a JSON string key to 
whatever you want for your clojure key - see 3rd example in 
https://github.com/dakrone/cheshire#decoding
So you could have something like:
 
(ns chtst.core
  (:require [cheshire.core :refer [parse-string]]
            [clojure.pprint :refer [pprint]])
  (:gen-class))

(def fields { "name" ::name, "age" ::age})

(defn -main
  [& args]
  (let [example (parse-string "{\"name\":\"fred\", \"age\":29}" fields)]
    (pprint example)))



However this doesn't produce good results if your JSON contains a key you 
haven't listed in fields - so you'd probably have to write an actual function 
to do the mapping.

Does that help?
Pete
-- 
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.

[ANN] core.specs.alpha 0.1.24

[Alex Miller]

core.specs.alpha is a Clojure library containining specs to describe 
Clojure core macros and functions.

core.specs.alpha 0.1.24 is now available. core.specs.alpha is included 
automatically as a dependency of Clojure in the 1.9 alphas, but you can 
also hard code this to pull in a newer version than the current alpha.

Try it via:  [org.clojure/core.specs.alpha "0.1.24"]

0.1.24 includes the following changes since 0.1.10:

   - CLJ-2219  - `require` 
   prefix lists were incorrectly spec'ed
   - CLJ-2220  - `use` prefix 
   lists were incorrectly spec'ed
   - dependencies on clojure and spec.alpha are now listed as provided so 
   are not treated as transitive deps

Also see: https://github.com/clojure/core.specs.alpha

-- 
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.