Re: s/valid? does not tell me if the data is valid as supplied

[Alex Miller]

On Wednesday, February 21, 2018 at 7:34:00 PM UTC-6, Didier wrote:
>
> I would actually love it if Spec was extended to have the concept of types.
>

Map specs are about attribute aggregation, not about types.

https://clojure.org/about/spec#_map_specs_should_be_of_keysets_only
 

> Something where every spec could be tied to a Type, and types could be 
> constructed to have Hierarchies.
>

You can effectively do this already. When you have s/keys maps which are 
sets of attributes, you can simply combine sets (base and extensions) using 
s/merge. Or when needing more polymorphism, s/multi-spec.

-- 
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: s/valid? does not tell me if the data is valid as supplied

[Didier]

I would actually love it if Spec was extended to have the concept of types.

Something where every spec could be tied to a Type, and types could be 
constructed to have Hierarchies.

Not sure what the syntax would be like, but say:

(s/def :String ::name string?)
(s/def :String ::address (s/and string? (complement string/blank?)))
(s/def :Person ::person (s/keys :req [::name ::address]))
(s/def :Homeless ::homeless (s/keys :req [::name]))

(s/defisa :Homeless :Person)

Types would still be predicates, and all spec would be a Type too. Types 
would be optional though. A Type is the OR of all the specs predicates 
defined as that Type and its children types. So in the above, :Homeless is 
(s/or ::person ::homeless).

Now, this idea might need to be refined, but the goal would be so that Spec 
could be used as a modeling languages for other languages. So I could from 
a Spec auto-generate a Java class model, or a Ruby model, etc. Since now I 
can relate predicates to types myself. It could also allow for better 
static analysis.

Also, might make spec extra complicated and confused to mix both predicates 
and types, but that could depend how its done and managed.

On Tuesday, 20 February 2018 02:41:38 UTC-8, Jan Rychter wrote:
>
> I've been using spec for a while now, in a reasonably large code base 
> (>30k lines of Clojure and ClojureScript) and there is an issue that bit me 
> several times.
>
> I use conformers for coercing data that is *almost* what I need, usually 
> when reading from JSON (RethinkDB). Common conformers are keyword and set. 
> And it works really well, except for one problem: there is no way to know 
> if data has been conformed or not.
>
> Calling s/valid? will tell me if the data is valid *if it has been 
> conformed*. But what if it hasn't? Can I use the data? Is it "valid" 
> according to the spec I wrote?
>
> This is a very real problem: I've spent considerable time chasing bugs 
> where there was a code path which did not call s/conform. The data passed 
> all validations done with valid? and the bug manifested itself far down the 
> road, where something expected a keyword instead of a string, or a set 
> instead of a vector.
>
> Here is a specific minimal example demonstrating what I'm talking about:
>
> (ns spectest
>   (:require [clojure.spec.alpha :as s]))
>
> (s/def ::test-spec (s/and (s/conformer keyword) keyword?))
>
> (s/conform ::test-spec "a") ;; :a
> (s/valid? ::test-spec "a") ;; true
>
> I expected the last valid? to return false, because my code does not 
> expect a string, it expects a keyword, according to the spec.
>
> I might be missing something, but I would much rather see valid? tell me 
> if the data is valid for use (as supplied) and have a separate 
> valid-when-conformed? which tells me if the data is, well, valid when 
> conformed. It seems to me that the current valid? that does two things is 
> confusing and not very useful for contracts.
>
> At the very least I'd really like to see a function that tells me if the 
> data is valid *as supplied*, as this is the function that I'd want to use 
> when enforcing contracts everywhere in my code.
>
> Alternatively, I could stop using conformers altogether, and write 
> explicit data conversion functions. That might not be a bad idea, but it 
> seems other people started using conformers, too, so eventually I'll hit 
> the same problem again.
>
> --J.
>
>

-- 
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: s/valid? does not tell me if the data is valid as supplied

[Sean Corfield]

Looking around I see lots of cases where people do use conformers for coercion.

That doesn’t make them right 

At a first glance it seems very natural, and warnings not to do it are not 
easily found.

Every single time coercion comes up anywhere in the context of spec, someone 
says “don’t do that”, and they’ve been saying it since the earliest alpha 
versions of spec. You would be correct to point out that nothing in the spec 
overview or spec guide on clojure.org carries this caution, however (and I 
think it’s a reasonable “ask” for the guide to be updated to include such a 
caution).

My recommendation is to have a strictly non-coercive spec for the target data 
“type” / shape you want, and to have a second spec that combines the coercion 
you want with that spec. That way you have a way to tell if your uncoerced data 
conforms to the spec, as well as a way to do coercion in s/conform. They are – 
and should be – two separate specs and two separate operations. They represent 
different layers of abstraction inside your application (so “of course” they 
should be two separate specs, one built on top of the other).

Given that the overview and the guide don’t even mention s/conformer, I’m not 
sure where that recommendation should live. Alex, any thoughts on this, since 
you seem to be the one most often making the recommendation?

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: clojure@googlegroups.com  on behalf of Jan 
Rychter 
Sent: Wednesday, February 21, 2018 1:16:49 AM
To: Clojure
Subject: Re: s/valid? does not tell me if the data is valid as supplied

On Tuesday, February 20, 2018 at 4:53:33 PM UTC+1, Alex Miller wrote:
This is exactly why we recommend that you not use conformers for coercion. 
Conformers were added primarily as a tool for building custom composite spec 
types (for example, we used it to build keys* from keys).

I am afraid that ship has sailed. Looking around I see lots of cases where 
people do use conformers for coercion. At a first glance it seems very natural, 
and warnings not to do it are not easily found.

This is a common need though and I would be happier if spec did more to help 
you solve it in a way that minimized repetition and maximized the use of 
existing specs. I'm still thinking through what that would mean exactly. It's 
challenging right now to plug externally without rebuilding a significant part 
of spec, so that's obviously not ideal.

Ideally, you would be able to say the things that are important here:

- the spec of the incoming data (strings or whatever - JSON sourced is the 
major use case)
- the spec of the data I desire
- the coercion functions that can move from one to the other (there are 
probably a small number of these that are widely reused)
- some way to coerce+validate or coerce+conform

Building coercion into a single spec itself instead leads to the problem of not 
being able to know what the source data actually was, and that's really at odds 
with the spec philosophy and the notion of bidirectional conforming.

I'm glad you see the need, highlighting it was largely the point of my post. As 
for these requirements, I agree, although I'm not sure about the need to know 
about the source.

Regardless of larger future plans, I think my original suggestion still stands: 
it would be nice to have a function that would tell me if the data is valid as 
supplied.

And another minor point: when I call a validation function (as part of contract 
checking), I do not necessarily expect to deal with all kinds of exceptions 
that coercion functions might throw.

--J.


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

Re: [ANN] Programming Clojure, 3rd edition

[Michael Glaesemann]

Congrats!

> On 2018-02-21, at 10:04, Alex Miller  wrote:
> 
> The 3rd edition of Programming Clojure is now available on Pragmatic:
> 
> https://pragprog.com/book/shcloj3/programming-clojure-third-edition
> 
> The 1st edition was the first Clojure book available and was written by 
> Stuart Halloway around Clojure 1.0. The second edition was an update by Aaron 
> Bedra around Clojure 1.3 timeframe. 
> 
> This 3rd edition is an update by me bringing everything up to date with 
> Clojure 1.9. There is a new chapter on spec, a new section on transducers (as 
> a more intermediate topic, this is really just an intro - Clojure Applied has 
> more detail), a bit on clj (what I could do based on timing), and many small 
> updates throughout.
> 
> Alex
> 
> -- 
> 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.

Michael Glaesemann
grzm seespotcode net



-- 
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] Programming Clojure, 3rd edition

[Alex Miller]

The 3rd edition of Programming Clojure is now available on Pragmatic:

https://pragprog.com/book/shcloj3/programming-clojure-third-edition

The 1st edition was the first Clojure book available and was written by 
Stuart Halloway around Clojure 1.0. The second edition was an update by 
Aaron Bedra around Clojure 1.3 timeframe. 

This 3rd edition is an update by me bringing everything up to date with 
Clojure 1.9. There is a new chapter on spec, a new section on transducers 
(as a more intermediate topic, this is really just an intro - Clojure 
Applied has more detail), a bit on clj (what I could do based on timing), 
and many small updates throughout.

Alex

-- 
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: [ANN] test-runner, a test runner for projects using Clojure Deps

[Andy Fingerhut]

Any call to clojure.core/future will also cause this 60-second delay,
including calls to pmap or clojure.java.shell/sh:
http://clojuredocs.org/clojure.core/future

Andy

On Tue, Feb 20, 2018 at 8:14 PM, 'Avi Flax' via Clojure <
clojure@googlegroups.com> wrote:

> On Tuesday, 20 February 2018 12:10:01 UTC-5, Luke VanderHart wrote:
>>
>> You're very likely correct about shutdown-agents, I don't think I
>> happened to fire up any agents in my test code. I'll try to reproduce as
>> soon as I get a chance.
>>
>
> FWIW, I’m seeing the same delay, and my project doesn’t use agents — at
> least, my project’s code doesn’t. I added a dummy test that calls
> (shutdown-agents) and that removed the delay, so I guess one of my
> dependencies is starting an agent; I have no idea which.
>
> 
> Principal Engineer @ Funding Circle
> Our mission: To build a better financial world
> We’re hiring! http://app.jobvite.com/m?34fSyjwx
>
>
> Our Mission: To build a better financial world
>
> Unless specifically indicated, this e-mail is not an offer to sell or a
> solicitation of any investment products or other financial product or
> service, an official confirmation of any transaction, or an official
> statement of Funding Circle USA.  This e-mail is meant only for the
> intended recipient of this transmission, and contains trade secret
> and strictly confidential information belonging to the sender. It is
> unlawful for unauthorized individuals to review, use, copy, disclose, or
> disseminate confidential information. If you have received this e-mail in
> error, please notify the sender immediately by telephone at (415) 813-5245 or 
> by
> return email and promptly delete this message from your system.
>
> --
> 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: s/valid? does not tell me if the data is valid as supplied

[Jan Rychter]

On Tuesday, February 20, 2018 at 4:53:33 PM UTC+1, Alex Miller wrote:
>
> This is exactly why we recommend that you not use conformers for coercion. 
> Conformers were added primarily as a tool for building custom composite 
> spec types (for example, we used it to build keys* from keys).
>

I am afraid that ship has sailed. Looking around I see lots of cases where 
people do use conformers for coercion. At a first glance it seems very 
natural, and warnings not to do it are not easily found.
 

> This is a common need though and I would be happier if spec did more to 
> help you solve it in a way that minimized repetition and maximized the use 
> of existing specs. I'm still thinking through what that would mean exactly. 
> It's challenging right now to plug externally without rebuilding a 
> significant part of spec, so that's obviously not ideal.
>
> Ideally, you would be able to say the things that are important here:
>
> - the spec of the incoming data (strings or whatever - JSON sourced is the 
> major use case)
> - the spec of the data I desire
> - the coercion functions that can move from one to the other (there are 
> probably a small number of these that are widely reused)
> - some way to coerce+validate or coerce+conform
>
> Building coercion into a single spec itself instead leads to the problem 
> of not being able to know what the source data actually was, and that's 
> really at odds with the spec philosophy and the notion of bidirectional 
> conforming.
>

I'm glad you see the need, highlighting it was largely the point of my 
post. As for these requirements, I agree, although I'm not sure about the 
need to know about the source.

Regardless of larger future plans, I think my original suggestion still 
stands: it would be nice to have a function that would tell me if the data 
is valid as supplied.

And another minor point: when I call a validation function (as part of 
contract checking), I do not necessarily expect to deal with all kinds of 
exceptions that coercion functions might throw.

--J.

-- 
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] re-graph 0.1.4 - the GraphQL client for Clojurescript

[Oliver Hine]

Hi everyone,

I'm pleased to announce the release of re-graph 0.1.4 
. re-graph is a 
GraphQL client for Clojurescript with re-frame bindings and support for 
queries, subscriptions and mutations over websocket or HTTP.

This release *adds support for*:

   - Providing arbitrary parameters to the underlying cljs-http request 
   used with the HTTP transport. This allows, among other things, 
   authorisation. See #13  for 
   details, thanks to @chrisbetz 
   - Ability to destroy the re-graph state, including stopping all 
   subscriptions and closing the websocket first. See #12 
    for details.

This release *improves*:

   - Subscriptions are deduplicated by id, helping to reduce workload on 
   servers which do not support deduplication #16 
   
   - Unsuccessful reconnection attempts no longer add messages to the 
   websocket queue #17 
   - Should work better with advanced compilation #15 
   


   
It's available now on Clojars.

Thanks and enjoy,
Oliy

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