Re: clojure.spec merge+or bug?

[Alex Whitt]

I got bitten by this today as well... makes it hard to add a predicate that 
destructures the map and compares its values. 

On Friday, August 17, 2018 at 4:35:12 PM UTC-4, Alex Miller wrote:
>
> With s/and, conformed values flow through the predicates. This allows you 
> to take advantage of structured values from early preds in later preds, so 
> you're not having to re-understand the structure. (There are cases where 
> having a non-flowing s/and would be useful and we've talked about adding 
> that since way back, still TBD). For single values, there's not much 
> difference, but it matters when you've got more structure, either from 
> regex (really s/& then) or s/or, etc.
>
> With s/merge the idea is to combine 2 or more map specs and "merge" their 
> specs, both during conform and gen. The mental picture I have is that the 
> same data flows into all the merged preds in parallel (whereas s/and snakes 
> them through in serial order). I don't have a good example at hand that 
> illustrates where is critical, but certainly in cases where you combining 
> s/keys with a collection view of map tuples with s/coll (sometimes called 
> "hybrid maps"), this is essential. 
>
>
>
> On Friday, August 17, 2018 at 2:36:23 PM UTC-5, Jenny Finkel wrote:
>>
>> Sorry, I meant to file a bug and even try to write a fix, but I was very 
>> pregnant at the time and then I gave birth so it sort of fell by the 
>> wayside. I'm interested in understanding why non-flowing behavior on 
>> conform is expected/desired behavior. I've found that when clojure design 
>> decisions go contrary to my intuitions, I usually learn a lot from 
>> understanding the design motivation. Would you mind explaining?
>> Cheers,
>>  Jenny
>> PS - I did try to google for an answer, and I found the thread where the 
>> docstring for merge got updated to reflect this, but I couldn't find an 
>> explanation.
>>
>> On Thu, Aug 16, 2018 at 7:00 PM, > 
>> wrote:
>>
>>> Thank you for explaining!
>>>
>>> Just in case, I opened a bug here 
>>> https://dev.clojure.org/jira/browse/CLJ-2388 
>>>
>>> On Thursday, August 16, 2018 at 6:47:30 PM UTC-7, Alex Miller wrote:

 The non-flowing behavior on conform is expected behavior.

 Failure to roundtrip conform then unform is a bug (so I'd so the bug 
 here is in unform).

 On a quick search, I don't believe this was filed, but I could have 
 missed it.

 On Thursday, August 16, 2018 at 8:28:54 PM UTC-5, shlomi...@gmail.com 
 wrote:
>
> Achhh, just spent the last few hours fighting this unexpected behavior 
> with s/merge, until I finally came to realize that this is what it was..
>
> I see this thread is quite old, did anyone open a bug for it as 
> mentioned above? 
>
> @Alex, you said this was the expected behavior, but then asked to open 
> a bug because it does not round-trip.. I am slightly confused, does the 
> problem lie in this "expected" behavior, or does it lie in s/unform? How 
> would such a bug be closed?
>
> Thanks,
> Shlomi
>
> On Thursday, June 1, 2017 at 6:24:25 AM UTC-7, Alex Miller wrote:
>>
>> You can file a bug on the s/merge unform - anything that doesn't 
>> roundtrip should be a bug.
>>
>> On the coll-of one, I thought that was just fixed in the latest 
>> spec.alpha release (see https://dev.clojure.org/jira/browse/CLJ-2076) 
>> - are you using latest there?
>>
> -- 
>>> 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
>>> clo...@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 a topic in the 
>>> Google Groups "Clojure" group.
>>> To unsubscribe from this topic, visit 
>>> https://groups.google.com/d/topic/clojure/r8WO24rHsi0/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to 
>>> clo...@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.
To view this discussion on 

Re: In clojure.spec, how to declare all valid keys in a map

[刘鑫]

lain ::my-map {::a 1 ::b 2 ::BAD 3})
>>>> In: [:user/b] val: 2 fails spec: :user/b at: [:user/b] predicate: 
>>>> string?
>>>>
>>>> ;; vs:
>>>>
>>>> (s/def ::my-map2 (s/merge (s/keys :req [::a ::b])  (s/map-of #{::a ::b} 
>>>> any?)))
>>>> (s/explain ::my-map2 {::a 1 ::b 2 ::BAD 3})
>>>> In: [:user/b] val: 2 fails spec: :user/b at: [:user/b] predicate: 
>>>> string?
>>>> In: [:user/BAD 0] val: :user/BAD fails spec: :user/my-map2 at: [0] 
>>>> predicate: #{:user/a :user/b}
>>>>
>>>> ^^ Note you get *both* failures here - both bad attribute value AND the 
>>>> invalid key vs the prior one where you only get the first failure.
>>>>
>>>>
>>>> On Tuesday, September 20, 2016 at 11:38:47 AM UTC-5, Beau Fabry wrote:
>>>>>
>>>>> boot.user=> (s/def ::my-map (s/and (s/keys :req [::a ::b])  (s/map-of 
>>>>> #{::a ::b} any?)))
>>>>> boot.user=> (s/explain ::my-map {::a 1 ::b 2 ::BAD 3})
>>>>> In: [:boot.user/BAD 0] val: :boot.user/BAD fails spec: 
>>>>> :boot.user/my-map at: [0] predicate: #{:boot.user/a :boot.user/b}
>>>>>
>>>>> Seems better
>>>>>
>>>>> On Tuesday, September 20, 2016 at 5:38:10 AM UTC-7, David Goldfarb 
>>>>> wrote:
>>>>>>
>>>>>> In clojure.spec, how can I declare a map that accepts only certain 
>>>>>> keys?  
>>>>>>
>>>>>> *{::a 1 ::b 2 ::BAD 3}* does conform to *(s/keys :req :req [::a 
>>>>>> ::b])*, but I want a spec that will be bothered by ::BAD or any 
>>>>>> other undeclared key.
>>>>>>
>>>>>> My use case: I am introducing spec to some legacy code, and I want to 
>>>>>> be warned if I have failed to specify some elements that may appear in 
>>>>>> my 
>>>>>> map.
>>>>>>
>>>>>>
>>>>>> Question 2:
>>>>>>
>>>>>>  So, assuming that this is not possible currently, I brute-forced it 
>>>>>> with:
>>>>>>
>>>>>> *(defn- key-checker [valid-keys]*
>>>>>> *  (fn [map-to-check]*
>>>>>> *(empty? (clojure.set/difference (into #{} (keys map-to-check)) 
>>>>>> valid-keys*
>>>>>>
>>>>>> *(s/def ::my-map (s/and (s/keys :req [::a ::b])  (key-checker #{::a 
>>>>>> ::b})))*
>>>>>>
>>>>>>
>>>>>> Ignoring the ugly, and easily fixable, smell of the duplicated set of 
>>>>>> keys, this has a bigger problem:
>>>>>>
>>>>>> If the predicate fails, the error that assert gives me is *"{... big 
>>>>>> ugly map ...} fails predicate: (key-checker #{::a ::b})"* with no 
>>>>>> easy way for the viewer to see which key failed. Can I somehow hook into 
>>>>>> the explain mechanism to give a more useful message?
>>>>>>
>>>>>

-- 
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] Serene - generate clojure.spec with GraphQL and extend GraphQL with clojure.spec

[Dom Kiva-Meyer]

 

https://github.com/paren-com/serene


Serene ingests GraphQL schemas and outputs Clojure specs. Serene is the 
easiest way to spec an entire API, whether internal or external.


These specs can be used for:

   - validating API input 
   - validating API output 
   - speccing resolvers 
   - speccing functions that receive or return API data 
   - generating mock data that conforms 
   - and anything else where you might use specs 


We announced Serene at Clojure/conj. Here is the video: 
https://www.youtube.com/watch?v=mgSSVTDZvkI


If you're using GraphQL, please give Serene a try.

-- 
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: clojure.spec merge+or bug?

[Alex Miller]

With s/and, conformed values flow through the predicates. This allows you 
to take advantage of structured values from early preds in later preds, so 
you're not having to re-understand the structure. (There are cases where 
having a non-flowing s/and would be useful and we've talked about adding 
that since way back, still TBD). For single values, there's not much 
difference, but it matters when you've got more structure, either from 
regex (really s/& then) or s/or, etc.

With s/merge the idea is to combine 2 or more map specs and "merge" their 
specs, both during conform and gen. The mental picture I have is that the 
same data flows into all the merged preds in parallel (whereas s/and snakes 
them through in serial order). I don't have a good example at hand that 
illustrates where is critical, but certainly in cases where you combining 
s/keys with a collection view of map tuples with s/coll (sometimes called 
"hybrid maps"), this is essential. 



On Friday, August 17, 2018 at 2:36:23 PM UTC-5, Jenny Finkel wrote:
>
> Sorry, I meant to file a bug and even try to write a fix, but I was very 
> pregnant at the time and then I gave birth so it sort of fell by the 
> wayside. I'm interested in understanding why non-flowing behavior on 
> conform is expected/desired behavior. I've found that when clojure design 
> decisions go contrary to my intuitions, I usually learn a lot from 
> understanding the design motivation. Would you mind explaining?
> Cheers,
>  Jenny
> PS - I did try to google for an answer, and I found the thread where the 
> docstring for merge got updated to reflect this, but I couldn't find an 
> explanation.
>
> On Thu, Aug 16, 2018 at 7:00 PM,  wrote:
>
>> Thank you for explaining!
>>
>> Just in case, I opened a bug here 
>> https://dev.clojure.org/jira/browse/CLJ-2388 
>>
>> On Thursday, August 16, 2018 at 6:47:30 PM UTC-7, Alex Miller wrote:
>>>
>>> The non-flowing behavior on conform is expected behavior.
>>>
>>> Failure to roundtrip conform then unform is a bug (so I'd so the bug 
>>> here is in unform).
>>>
>>> On a quick search, I don't believe this was filed, but I could have 
>>> missed it.
>>>
>>> On Thursday, August 16, 2018 at 8:28:54 PM UTC-5, shlomi...@gmail.com 
>>> wrote:

 Achhh, just spent the last few hours fighting this unexpected behavior 
 with s/merge, until I finally came to realize that this is what it was..

 I see this thread is quite old, did anyone open a bug for it as 
 mentioned above? 

 @Alex, you said this was the expected behavior, but then asked to open 
 a bug because it does not round-trip.. I am slightly confused, does the 
 problem lie in this "expected" behavior, or does it lie in s/unform? How 
 would such a bug be closed?

 Thanks,
 Shlomi

 On Thursday, June 1, 2017 at 6:24:25 AM UTC-7, Alex Miller wrote:
>
> You can file a bug on the s/merge unform - anything that doesn't 
> roundtrip should be a bug.
>
> On the coll-of one, I thought that was just fixed in the latest 
> spec.alpha release (see https://dev.clojure.org/jira/browse/CLJ-2076) 
> - are you using latest there?
>
 -- 
>> 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 a topic in the 
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/clojure/r8WO24rHsi0/unsubscribe.
>> To unsubscribe from this group and all its topics, 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: clojure.spec merge+or bug?

[Jenny Finkel]

Sorry, I meant to file a bug and even try to write a fix, but I was very
pregnant at the time and then I gave birth so it sort of fell by the
wayside. I'm interested in understanding why non-flowing behavior on
conform is expected/desired behavior. I've found that when clojure design
decisions go contrary to my intuitions, I usually learn a lot from
understanding the design motivation. Would you mind explaining?
Cheers,
 Jenny
PS - I did try to google for an answer, and I found the thread where the
docstring for merge got updated to reflect this, but I couldn't find an
explanation.

On Thu, Aug 16, 2018 at 7:00 PM,  wrote:

> Thank you for explaining!
>
> Just in case, I opened a bug here https://dev.clojure.org/jira/
> browse/CLJ-2388
>
> On Thursday, August 16, 2018 at 6:47:30 PM UTC-7, Alex Miller wrote:
>>
>> The non-flowing behavior on conform is expected behavior.
>>
>> Failure to roundtrip conform then unform is a bug (so I'd so the bug here
>> is in unform).
>>
>> On a quick search, I don't believe this was filed, but I could have
>> missed it.
>>
>> On Thursday, August 16, 2018 at 8:28:54 PM UTC-5, shlomi...@gmail.com
>> wrote:
>>>
>>> Achhh, just spent the last few hours fighting this unexpected behavior
>>> with s/merge, until I finally came to realize that this is what it was..
>>>
>>> I see this thread is quite old, did anyone open a bug for it as
>>> mentioned above?
>>>
>>> @Alex, you said this was the expected behavior, but then asked to open a
>>> bug because it does not round-trip.. I am slightly confused, does the
>>> problem lie in this "expected" behavior, or does it lie in s/unform? How
>>> would such a bug be closed?
>>>
>>> Thanks,
>>> Shlomi
>>>
>>> On Thursday, June 1, 2017 at 6:24:25 AM UTC-7, Alex Miller wrote:

 You can file a bug on the s/merge unform - anything that doesn't
 roundtrip should be a bug.

 On the coll-of one, I thought that was just fixed in the latest
 spec.alpha release (see https://dev.clojure.org/jira/browse/CLJ-2076)
 - are you using latest there?

>>> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/r8WO24rHsi0/unsubscribe.
> To unsubscribe from this group and all its topics, 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: clojure.spec merge+or bug?

[shlomivaknin]

Thank you for explaining!

Just in case, I opened a bug here 
https://dev.clojure.org/jira/browse/CLJ-2388 

On Thursday, August 16, 2018 at 6:47:30 PM UTC-7, Alex Miller wrote:
>
> The non-flowing behavior on conform is expected behavior.
>
> Failure to roundtrip conform then unform is a bug (so I'd so the bug here 
> is in unform).
>
> On a quick search, I don't believe this was filed, but I could have missed 
> it.
>
> On Thursday, August 16, 2018 at 8:28:54 PM UTC-5, shlomi...@gmail.com 
>  wrote:
>>
>> Achhh, just spent the last few hours fighting this unexpected behavior 
>> with s/merge, until I finally came to realize that this is what it was..
>>
>> I see this thread is quite old, did anyone open a bug for it as mentioned 
>> above? 
>>
>> @Alex, you said this was the expected behavior, but then asked to open a 
>> bug because it does not round-trip.. I am slightly confused, does the 
>> problem lie in this "expected" behavior, or does it lie in s/unform? How 
>> would such a bug be closed?
>>
>> Thanks,
>> Shlomi
>>
>> On Thursday, June 1, 2017 at 6:24:25 AM UTC-7, Alex Miller wrote:
>>>
>>> You can file a bug on the s/merge unform - anything that doesn't 
>>> roundtrip should be a bug.
>>>
>>> On the coll-of one, I thought that was just fixed in the latest 
>>> spec.alpha release (see https://dev.clojure.org/jira/browse/CLJ-2076) - 
>>> are you using latest there?
>>>
>>

-- 
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: clojure.spec merge+or bug?

[Alex Miller]

The non-flowing behavior on conform is expected behavior.

Failure to roundtrip conform then unform is a bug (so I'd so the bug here 
is in unform).

On a quick search, I don't believe this was filed, but I could have missed 
it.

On Thursday, August 16, 2018 at 8:28:54 PM UTC-5, shlomivak...@gmail.com 
wrote:
>
> Achhh, just spent the last few hours fighting this unexpected behavior 
> with s/merge, until I finally came to realize that this is what it was..
>
> I see this thread is quite old, did anyone open a bug for it as mentioned 
> above? 
>
> @Alex, you said this was the expected behavior, but then asked to open a 
> bug because it does not round-trip.. I am slightly confused, does the 
> problem lie in this "expected" behavior, or does it lie in s/unform? How 
> would such a bug be closed?
>
> Thanks,
> Shlomi
>
> On Thursday, June 1, 2017 at 6:24:25 AM UTC-7, Alex Miller wrote:
>>
>> You can file a bug on the s/merge unform - anything that doesn't 
>> roundtrip should be a bug.
>>
>> On the coll-of one, I thought that was just fixed in the latest 
>> spec.alpha release (see https://dev.clojure.org/jira/browse/CLJ-2076) - 
>> are you using latest there?
>>
>

-- 
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: clojure.spec merge+or bug?

[shlomivaknin]

Achhh, just spent the last few hours fighting this unexpected behavior with 
s/merge, until I finally came to realize that this is what it was..

I see this thread is quite old, did anyone open a bug for it as mentioned 
above? 

@Alex, you said this was the expected behavior, but then asked to open a 
bug because it does not round-trip.. I am slightly confused, does the 
problem lie in this "expected" behavior, or does it lie in s/unform? How 
would such a bug be closed?

Thanks,
Shlomi

On Thursday, June 1, 2017 at 6:24:25 AM UTC-7, Alex Miller wrote:
>
> You can file a bug on the s/merge unform - anything that doesn't roundtrip 
> should be a bug.
>
> On the coll-of one, I thought that was just fixed in the latest spec.alpha 
> release (see https://dev.clojure.org/jira/browse/CLJ-2076) - are you 
> using latest there?
>

-- 
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: Order of preds in clojure.spec/alt

[J]

Hi Sean,

unfortunately the problem is more complex. The "default" predicate i am 
using is a second case which sometimes overlaps with the first pred.

For Example: 

(spec/alt :strings (spec/* string?)
   :length (spec/* #(< 1 (count (str %

on input ["string" 1 ] matches only "string" but on ["string" 11] it 
matches both.



Am Donnerstag, 2. August 2018 23:05:49 UTC+2 schrieb Sean Corfield:
>
> I would assume it’s a “maximal munch” strategy at play here: (spec/* 
> string?) will only match one string in your input but (spec/* identity) 
> will match all three elements so it “wins” as the best match.
>
>  
>
> Perhaps :default (spec/* (complement string?)) will do what you need? 
> (depending on exactly what you want to happen if you aren’t matching at 
> least one string?)
>
>  
>
> 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:* clo...@googlegroups.com   > on behalf of J >
> *Sent:* Thursday, August 2, 2018 6:31:15 AM
> *To:* Clojure
> *Subject:* Order of preds in clojure.spec/alt 
>  
> Hi there, 
>
> right now i am using spec to match some input data with something like 
> this 
>
>  (require '[clojure.spec.alpha :as spec])
>
>   (spec/conform (spec/cat :stuff (spec/alt
> :strings (spec/* string?)
>   ;:default (spec/* identity)
>  )
> :rest (spec/* identity))
>   ["some string" 2 2])
>
>
> => {:stuff [:strings ["some string"]], :rest [2 2]}
>
>
>
> But if i add a "default" to alt it returns something unexpected
>  
> (spec/conform (spec/cat :stuff (spec/alt
> :strings (spec/* string?)
>:default (spec/* identity))
> :rest (spec/* identity))
>   ["some string" 2 2])
>
> => {:stuff [:default ["some string" 2 2]]}
>
>
> The docs  
> https://clojure.github.io/spec.alpha/clojure.spec.alpha-api.html#clojure.spec.alpha/alt
>  
> says: 
> Returns a regex op that returns a map entry containing the key of the
>
> first matching pred and the corresponding value.
>
>
> I would expect that (spec/* string?) is the first matching pred and not the 
> (spec/* identitiy).
>
> Is this behavior correct?
>
>
> Thanks J
>
>
> -- 
> 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.
>

-- 
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: Order of preds in clojure.spec/alt

[Sean Corfield]

I would assume it’s a “maximal munch” strategy at play here: (spec/* string?) 
will only match one string in your input but (spec/* identity) will match all 
three elements so it “wins” as the best match.

Perhaps :default (spec/* (complement string?)) will do what you need? 
(depending on exactly what you want to happen if you aren’t matching at least 
one string?)

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 J 

Sent: Thursday, August 2, 2018 6:31:15 AM
To: Clojure
Subject: Order of preds in clojure.spec/alt

Hi there,

right now i am using spec to match some input data with something like this

 (require '[clojure.spec.alpha :as spec])

  (spec/conform (spec/cat :stuff (spec/alt
:strings (spec/* string?)
  ;:default (spec/* identity)
 )
:rest (spec/* identity))
  ["some string" 2 2])


=> {:stuff [:strings ["some string"]], :rest [2 2]}



But if i add a "default" to alt it returns something unexpected

(spec/conform (spec/cat :stuff (spec/alt
:strings (spec/* string?)
   :default (spec/* identity))
:rest (spec/* identity))
  ["some string" 2 2])

=> {:stuff [:default ["some string" 2 2]]}


The docs  
https://clojure.github.io/spec.alpha/clojure.spec.alpha-api.html#clojure.spec.alpha/alt
 says:
Returns a regex op that returns a map entry containing the key of the

first matching pred and the corresponding value.


I would expect that (spec/* string?) is the first matching pred and not the 
(spec/* identitiy).

Is this behavior correct?


Thanks 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<mailto: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.

Order of preds in clojure.spec/alt

[J]

Hi there,

right now i am using spec to match some input data with something like this 

 (require '[clojure.spec.alpha :as spec])

  (spec/conform (spec/cat :stuff (spec/alt
:strings (spec/* string?)
  ;:default (spec/* identity)
 )
:rest (spec/* identity))
  ["some string" 2 2])


=> {:stuff [:strings ["some string"]], :rest [2 2]}



But if i add a "default" to alt it returns something unexpected
 
(spec/conform (spec/cat :stuff (spec/alt
:strings (spec/* string?)
   :default (spec/* identity))
:rest (spec/* identity))
  ["some string" 2 2])

=> {:stuff [:default ["some string" 2 2]]}


The 
docs  
https://clojure.github.io/spec.alpha/clojure.spec.alpha-api.html#clojure.spec.alpha/alt
 
says: 
Returns a regex op that returns a map entry containing the key of the

first matching pred and the corresponding value.


I would expect that (spec/* string?) is the first matching pred and not the 
(spec/* identitiy).

Is this behavior correct?


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

Clojure.spec for maps with dependent values

[Timothy Washington]

Hello,

Is there a way to make a spec that describes a map where

   - i. a key can be from a set of values and
   - ii. the value chose is used as the key for another entry
   - iii. an additional map entry is added


For example, if we had the maps in *A.*, we could generate them with the
test.check generator(s) in *B.*

I think I've just been looking at this too long and can't seem to move that
to a function argument spec. Any tips?

*A.*

{:input-key :foo
 :foo 4.5
 :b 36865}


{:input-key :bar
 :bar 9.8
 :b 47895}



*B.*

(require [clojure.spec.alpha :as s]
 [clojure.spec.gen.alpha :as g]
 [clojure.test.check.generators :as gen])

(s/def ::input-key #{:foo :bar})

(def a-tuple (g/bind (s/gen ::input-key)
 (fn [x]
   (g/tuple (g/return x)
(g/double* {:min 1.0 :infinite? false,
:NaN? false})

(def b-tuple (g/tuple (g/return :b)
  (g/large-integer)))

(def my-map (gen/let [at a-tuple
  tt b-tuple]

  (->> [:input-key (first at)]
   (concat at tt)
   (apply array-map

(g/generate my-map)



Tim Washington
Interruptsoftware.com 

-- 
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: Thoughts on clojure.spec

[Dean Thompson]

For others, like me, who are finding this old thread interesting reading, 
there's a newer library that nicely addresses a concern expressed here, "Do 
you find it frustrating that there's no way to turn on instrumentation of 
function outputs for manual testing?"

I am really enjoying and getting value from orchestra 
.

Dean

-- 
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: clojure.spec gen-testing VS NaN

['Dirk Wetzel' via Clojure]

By definition NaN never equals any other number, including NaN itself, so 
isn't it a perfectly valid scenario to generate double NaNs?
(Note: I've not used spec yet, so correct me if I'm completely off track)


Am Montag, 7. November 2016 23:07:14 UTC+1 schrieb Alex Miller:
>
> I think it would be reasonable to log a jira enhancement request for the 
> spec any? generator to avoid generating double NaNs.
>
>
> On Monday, November 7, 2016 at 12:30:24 PM UTC-6, Jim foo.bar wrote:
>>
>> Hi Alex,
>>
>> Oh yeah I've seen `s/double-in` but as you point out that doesn't help me 
>> if I want to :ret spec a function with similar semantics as remove (a fn 
>> that transforms a seq given a predicate), which I find a very common 
>> indeed.  I'm only starting playing with clojure.spec (in fact i've only 
>> spec'ed 2 fns so far) and I've not yet had to spec specifically a 
>> double-precision number. I have had however the need to spec :any? as 
>> ::anything-but-NaN, in both my first 2 specs, so according to my experience 
>> this is by no means a rare issue. In fact, looking at clojure.core, most 
>> fns operate on seqs, and a good proportion of them processes/transforms a 
>> coll according to a predicate/fn. This has nothing to do with doubles or in 
>> fact numbers. We can only spec the contents of the collection as `any?` 
>> right? anything more specific, and the gen-surface area is reduced. So yeah 
>> it's great that we have `s/double-in`, but ideally I'd also like a reliable 
>> way to say that the output coll from a fn is equal to the input coll, while 
>> having specified the contents of that coll with `any?`, and without having 
>> to jump through hoops in the :ret spec. My workaround is actually working 
>> nicely for me, and i can certainly live without NaNs in the tests, but it 
>> still feels a bit hacky.
>>
>> Thanks,
>>
>> Dimitris
>>
>> On 07/11/16 18:14, Alex Miller wrote:
>>
>> Please also take a look at s/double-in, which allows you to exclude NaN 
>> (and Infinity/-Infinity) as valid values. 
>>
>> (I realize this does not address the any? question, but that seems like a 
>> rarer issue to me than cases where I'm explicitly spec'ing a double but 
>> don't want to allow NaN.)
>>
>> On Monday, November 7, 2016 at 11:37:08 AM UTC-6, Jim foo.bar wrote: 
>>>
>>> Hi all, 
>>>
>>> clojure.spec helped me realise that NaNs totally break [1] equality (per 
>>> `clojure.core/=`). Even though in real production code this might not be 
>>> an issue due to how infrequently one deals with NaNs, but during 
>>> gen-testing I've found them extremely annoying, and I've essentially 
>>> worked around this by spec-ing things I'd normally specify via `any?`, 
>>> via `(s/and any? (complement double-NaN?))` instead. I have to do this 
>>> for any spec, where in the :ret spec i need to be able to confirm that 
>>> the input coll is equal to the output coll (e.g. `clojure.core/remove` 
>>> returns the same coll it was passed in when nothing has been removed), 
>>> which is a possibility in a lot of functions. Have other people 
>>> encountered this as well, and if yes, how are you guys dealing with it? 
>>> Thanks in advance... 
>>>
>>> Kind regards, 
>>>
>>> Dimitris 
>>>
>>> [1]: (= [:a Double/NaN] [:a Double/NaN]) => false 
>>>
>>>
>>>
>>> -- 
>> 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.
>>
>>
>>

-- 
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: clojure.spec gen-testing VS NaN

[Wes Morgan]

Yes it did: https://dev.clojure.org/jira/browse/CLJ-2054

On Tuesday, March 6, 2018 at 12:15:26 PM UTC-7, Wes Morgan wrote:
>
> Did this ticket get created?
>
> On Monday, November 7, 2016 at 3:26:15 PM UTC-7, Jim foo.bar wrote:
>>
>> Alright cool, I'll do that tomorrow :) 
>>
>> Thanks,
>>
>> Dimitris
>>
>> On 07/11/16 22:07, Alex Miller wrote:
>>
>> I think it would be reasonable to log a jira enhancement request for the 
>> spec any? generator to avoid generating double NaNs. 
>>
>>
>> On Monday, November 7, 2016 at 12:30:24 PM UTC-6, Jim foo.bar wrote: 
>>>
>>> Hi Alex,
>>>
>>> Oh yeah I've seen `s/double-in` but as you point out that doesn't help 
>>> me if I want to :ret spec a function with similar semantics as remove (a fn 
>>> that transforms a seq given a predicate), which I find a very common 
>>> indeed.  I'm only starting playing with clojure.spec (in fact i've only 
>>> spec'ed 2 fns so far) and I've not yet had to spec specifically a 
>>> double-precision number. I have had however the need to spec :any? as 
>>> ::anything-but-NaN, in both my first 2 specs, so according to my experience 
>>> this is by no means a rare issue. In fact, looking at clojure.core, most 
>>> fns operate on seqs, and a good proportion of them processes/transforms a 
>>> coll according to a predicate/fn. This has nothing to do with doubles or in 
>>> fact numbers. We can only spec the contents of the collection as `any?` 
>>> right? anything more specific, and the gen-surface area is reduced. So yeah 
>>> it's great that we have `s/double-in`, but ideally I'd also like a reliable 
>>> way to say that the output coll from a fn is equal to the input coll, while 
>>> having specified the contents of that coll with `any?`, and without having 
>>> to jump through hoops in the :ret spec. My workaround is actually working 
>>> nicely for me, and i can certainly live without NaNs in the tests, but it 
>>> still feels a bit hacky.
>>>
>>> Thanks,
>>>
>>> Dimitris
>>>
>>> On 07/11/16 18:14, Alex Miller wrote:
>>>
>>> Please also take a look at s/double-in, which allows you to exclude NaN 
>>> (and Infinity/-Infinity) as valid values. 
>>>
>>> (I realize this does not address the any? question, but that seems like 
>>> a rarer issue to me than cases where I'm explicitly spec'ing a double but 
>>> don't want to allow NaN.)
>>>
>>> On Monday, November 7, 2016 at 11:37:08 AM UTC-6, Jim foo.bar wrote: 
>>>>
>>>> Hi all, 
>>>>
>>>> clojure.spec helped me realise that NaNs totally break [1] equality 
>>>> (per 
>>>> `clojure.core/=`). Even though in real production code this might not 
>>>> be 
>>>> an issue due to how infrequently one deals with NaNs, but during 
>>>> gen-testing I've found them extremely annoying, and I've essentially 
>>>> worked around this by spec-ing things I'd normally specify via `any?`, 
>>>> via `(s/and any? (complement double-NaN?))` instead. I have to do this 
>>>> for any spec, where in the :ret spec i need to be able to confirm that 
>>>> the input coll is equal to the output coll (e.g. `clojure.core/remove` 
>>>> returns the same coll it was passed in when nothing has been removed), 
>>>> which is a possibility in a lot of functions. Have other people 
>>>> encountered this as well, and if yes, how are you guys dealing with it? 
>>>> Thanks in advance... 
>>>>
>>>> Kind regards, 
>>>>
>>>> Dimitris 
>>>>
>>>> [1]: (= [:a Double/NaN] [:a Double/NaN]) => false 
>>>>
>>>>
>>>>
>>>> -- 
>>> 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...@goo

Re: clojure.spec gen-testing VS NaN

[Wes Morgan]

Did this ticket get created?

On Monday, November 7, 2016 at 3:26:15 PM UTC-7, Jim foo.bar wrote:
>
> Alright cool, I'll do that tomorrow :) 
>
> Thanks,
>
> Dimitris
>
> On 07/11/16 22:07, Alex Miller wrote:
>
> I think it would be reasonable to log a jira enhancement request for the 
> spec any? generator to avoid generating double NaNs. 
>
>
> On Monday, November 7, 2016 at 12:30:24 PM UTC-6, Jim foo.bar wrote: 
>>
>> Hi Alex,
>>
>> Oh yeah I've seen `s/double-in` but as you point out that doesn't help me 
>> if I want to :ret spec a function with similar semantics as remove (a fn 
>> that transforms a seq given a predicate), which I find a very common 
>> indeed.  I'm only starting playing with clojure.spec (in fact i've only 
>> spec'ed 2 fns so far) and I've not yet had to spec specifically a 
>> double-precision number. I have had however the need to spec :any? as 
>> ::anything-but-NaN, in both my first 2 specs, so according to my experience 
>> this is by no means a rare issue. In fact, looking at clojure.core, most 
>> fns operate on seqs, and a good proportion of them processes/transforms a 
>> coll according to a predicate/fn. This has nothing to do with doubles or in 
>> fact numbers. We can only spec the contents of the collection as `any?` 
>> right? anything more specific, and the gen-surface area is reduced. So yeah 
>> it's great that we have `s/double-in`, but ideally I'd also like a reliable 
>> way to say that the output coll from a fn is equal to the input coll, while 
>> having specified the contents of that coll with `any?`, and without having 
>> to jump through hoops in the :ret spec. My workaround is actually working 
>> nicely for me, and i can certainly live without NaNs in the tests, but it 
>> still feels a bit hacky.
>>
>> Thanks,
>>
>> Dimitris
>>
>> On 07/11/16 18:14, Alex Miller wrote:
>>
>> Please also take a look at s/double-in, which allows you to exclude NaN 
>> (and Infinity/-Infinity) as valid values. 
>>
>> (I realize this does not address the any? question, but that seems like a 
>> rarer issue to me than cases where I'm explicitly spec'ing a double but 
>> don't want to allow NaN.)
>>
>> On Monday, November 7, 2016 at 11:37:08 AM UTC-6, Jim foo.bar wrote: 
>>>
>>> Hi all, 
>>>
>>> clojure.spec helped me realise that NaNs totally break [1] equality (per 
>>> `clojure.core/=`). Even though in real production code this might not be 
>>> an issue due to how infrequently one deals with NaNs, but during 
>>> gen-testing I've found them extremely annoying, and I've essentially 
>>> worked around this by spec-ing things I'd normally specify via `any?`, 
>>> via `(s/and any? (complement double-NaN?))` instead. I have to do this 
>>> for any spec, where in the :ret spec i need to be able to confirm that 
>>> the input coll is equal to the output coll (e.g. `clojure.core/remove` 
>>> returns the same coll it was passed in when nothing has been removed), 
>>> which is a possibility in a lot of functions. Have other people 
>>> encountered this as well, and if yes, how are you guys dealing with it? 
>>> Thanks in advance... 
>>>
>>> Kind regards, 
>>>
>>> Dimitris 
>>>
>>> [1]: (= [:a Double/NaN] [:a Double/NaN]) => false 
>>>
>>>
>>>
>>> -- 
>> 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.
>>
>>
>> -- 
> 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 gro

Re: [clojure.spec] Best practices for programmatically generating specs?

[Aaron Brooks]

An eval requirement will still be an impediment to me but it's good to hear 
that things are still being worked on. I'm happy to do any early testing of 
proposed approaches and give feedback.

Thanks for letting me know -- keep us posted!

-Aaron

On Wednesday, December 13, 2017 at 10:45:56 PM UTC-5, Alex Miller wrote:
>
> Another possible option is using spec specs (CLJ-2112) to unform from a 
> spec data form to a spec (but that would still need to be evaluated) - 
> still very much a wip.
>
> However, we are working on a spec update that will target some of this, so 
> stay tuned for that.
>
>
>
> On Wednesday, December 13, 2017 at 5:14:34 PM UTC-6, Aaron Brooks wrote:
>>
>> I've found in several projects that I want to have families of specs that 
>> have some shared structure but some differing structure.
>>
>> Consider a case where I have some, possibly nested, structure which in 
>> some cases will have some type of  place-holder values which will later be 
>> replaced with actual values. I don't want a spec to have an 's/or at each 
>> position that could have a place-holder since I expect the structure to be 
>> populated with only place-holder values or only resolved values and want to 
>> exclude a mix.
>>
>> Neither do I want to maintain two versions of the spec by hand. Some of 
>> the structure is complex and would be a pain to keep the two in sync.
>>
>> This appears to leave two choices.
>>
>> I'd like to describe the spec and then walk the spec, generating the 
>> other spec instance. Due to the macro-y nature of spec, I think this means 
>> eval which makes this not cljc/cljs friendly for self-hosted ClojureScript.
>>
>> The alternative seems to be to build a set of macros that will generate 
>> both forms of the specs. This is awkward since it requires the full spec to 
>> be defined within the macro form and winds up being much more complex than 
>> a walk-and-transform of one spec into another.
>>
>> What is the best practice for generating specs like this? Am I missing 
>> something?
>>
>> I'm afraid the current macro-y, non-data-y implementation of 
>> clojure.spec.alpha really renders certain usage patterns (say specs that 
>> are derived from meta-specs) very awkward or inaccessible. I know spec 
>> needs to capture symbols and forms but wish that was a ease interface on 
>> top of a data oriented implementation that was first-class.
>>
>> Let me know if I'm missing something in how I'm thinking about this or 
>> what my available options are.
>>
>> Thanks!
>>
>> -Aaron
>>
>

-- 
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: [clojure.spec] Best practices for programmatically generating specs?

[Alex Miller]

Another possible option is using spec specs (CLJ-2112) to unform from a 
spec data form to a spec (but that would still need to be evaluated) - 
still very much a wip.

However, we are working on a spec update that will target some of this, so 
stay tuned for that.



On Wednesday, December 13, 2017 at 5:14:34 PM UTC-6, Aaron Brooks wrote:
>
> I've found in several projects that I want to have families of specs that 
> have some shared structure but some differing structure.
>
> Consider a case where I have some, possibly nested, structure which in 
> some cases will have some type of  place-holder values which will later be 
> replaced with actual values. I don't want a spec to have an 's/or at each 
> position that could have a place-holder since I expect the structure to be 
> populated with only place-holder values or only resolved values and want to 
> exclude a mix.
>
> Neither do I want to maintain two versions of the spec by hand. Some of 
> the structure is complex and would be a pain to keep the two in sync.
>
> This appears to leave two choices.
>
> I'd like to describe the spec and then walk the spec, generating the other 
> spec instance. Due to the macro-y nature of spec, I think this means eval 
> which makes this not cljc/cljs friendly for self-hosted ClojureScript.
>
> The alternative seems to be to build a set of macros that will generate 
> both forms of the specs. This is awkward since it requires the full spec to 
> be defined within the macro form and winds up being much more complex than 
> a walk-and-transform of one spec into another.
>
> What is the best practice for generating specs like this? Am I missing 
> something?
>
> I'm afraid the current macro-y, non-data-y implementation of 
> clojure.spec.alpha really renders certain usage patterns (say specs that 
> are derived from meta-specs) very awkward or inaccessible. I know spec 
> needs to capture symbols and forms but wish that was a ease interface on 
> top of a data oriented implementation that was first-class.
>
> Let me know if I'm missing something in how I'm thinking about this or 
> what my available options are.
>
> Thanks!
>
> -Aaron
>

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

[clojure.spec] Best practices for programmatically generating specs?

[Aaron Brooks]

I've found in several projects that I want to have families of specs that 
have some shared structure but some differing structure.

Consider a case where I have some, possibly nested, structure which in some 
cases will have some type of  place-holder values which will later be 
replaced with actual values. I don't want a spec to have an 's/or at each 
position that could have a place-holder since I expect the structure to be 
populated with only place-holder values or only resolved values and want to 
exclude a mix.

Neither do I want to maintain two versions of the spec by hand. Some of the 
structure is complex and would be a pain to keep the two in sync.

This appears to leave two choices.

I'd like to describe the spec and then walk the spec, generating the other 
spec instance. Due to the macro-y nature of spec, I think this means eval 
which makes this not cljc/cljs friendly for self-hosted ClojureScript.

The alternative seems to be to build a set of macros that will generate 
both forms of the specs. This is awkward since it requires the full spec to 
be defined within the macro form and winds up being much more complex than 
a walk-and-transform of one spec into another.

What is the best practice for generating specs like this? Am I missing 
something?

I'm afraid the current macro-y, non-data-y implementation of 
clojure.spec.alpha really renders certain usage patterns (say specs that 
are derived from meta-specs) very awkward or inaccessible. I know spec 
needs to capture symbols and forms but wish that was a ease interface on 
top of a data oriented implementation that was first-class.

Let me know if I'm missing something in how I'm thinking about this or what 
my available options are.

Thanks!

-Aaron

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

Feed predicates from clojure.spec to the inference engine/type checker from the Shen java port?

[Didier]

Oh, it also follows known values around, and runs them against the specs at 
static time. So it can catch some value based errors, like a divide by zero, 
given that the value is available at static time too.

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

Feed predicates from clojure.spec to the inference engine/type checker from the Shen java port?

[Didier]

I'm not sure how shen does it, but you should check out Spectrum: 
https://github.com/arohner/spectrum

It tries to do static analysis of your Clojure code based on your specs. My 
understanding of it is that it considers equal predicates to be a type. The 
challenge is knowing that two predicates are equal, or that one is a subtype of 
the other. I don't think its very dmart about that yet. But just cobsidering 
each spec as a type can catch a few bugs.

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

Feed predicates from clojure.spec to the inference engine/type checker from the Shen java port?

[Tiago Dall'Oca]

I'd very much appreciate this kind of thing. I'm not totally into neither 
static nor dynamic camp. I think we can be benefitted from ideas and 
philosophies of both.

Unfortunately I can't help by now but I guess there are people willing to. 

Maybe you should also reference this in other clojure channels? 

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

Feed predicates from clojure.spec to the inference engine/type checker from the Shen java port?

[lawrence . krubner]

This sounds like an interesting idea. Does anyone know if this could work? 

https://news.ycombinator.com/item?id=15569058

The allure of Shen is that it offers a type system that is, roughly 
speaking, very similar to what you get with clojure.spec. You construct 
"predicates", what Shen calls sequents, which hold about your data. Shen 
goes a step further than clojure.spec in that it offers a way to prove that 
those predicates hold locally to each function and globally through your 
program.

I wonder if it might be possible to feed predicates from clojure.spec to 
the inference engine/type checker from the Shen java port to gain static 
type checking. I wish I had more time to work on this kind of fundamental 
research, but alas I'm merely a working programmer schlepping data to and 
fro.

-- 
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: Very weird beahviour (bug ?) with clojure.spec

[Khalid Jebbari]

Shame on me, I had 2 spec with the same name in the same file... 
:slap-me-im-famous:

On Wednesday, September 27, 2017 at 11:48:27 AM UTC+2, Khalid Jebbari wrote:
>
> Hello,
>
> I've written a spec with an attached generator. The generator works ONLY 
> if I rename the spec (yes, the keyword), this is really weird.
>
> ---
> Environment :
>
> > java -version
> openjdk version "1.8.0_144"
> OpenJDK Runtime Environment (build 1.8.0_144-b01)
> OpenJDK 64-Bit Server VM (build 25.144-b01, mixed mode)
>
> [org.clojure/clojure "1.9.0-beta1"]
> [org.clojure/test.check "0.10.0-alpha2" :scope "test"]
>
> 
> Full code :
>
> (ns myns.specs
>   (:require [clojure.spec.alpha :as s]
> [clojure.string :as str]
> [clojure.test.check.generators :as g]))
>
> (def url-path (g/fmap #(apply str "/" %) (g/vector g/char-alphanumeric 5 
> 10)))
>
> (s/def :url/path (s/with-gen (s/and string? #(re-matches #"^(/.*)+" %))
>  (fn path-gen []
>(g/fmap #(apply str %) (g/vector url-path 1 
> 3)
>
> 
> Generation fails :
>
> (g/sample (s/gen :url/path) 3)
> clojure.lang.ExceptionInfo: Couldn't satisfy such-that predicate after 100 
> tries.
>
>
> 
> If I rename `:url/path` to `:url/path2` or `::path`, it works fine !
>
> I tried searching the source code of spec to see if there was already a 
> spec with the same name, but there was none. I have no idea where this 
> problem comes from. Any help appreciated.
>

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

Very weird beahviour (bug ?) with clojure.spec

[Khalid Jebbari]

Hello,

I've written a spec with an attached generator. The generator works ONLY if 
I rename the spec (yes, the keyword), this is really weird.

---
Environment :

> java -version
openjdk version "1.8.0_144"
OpenJDK Runtime Environment (build 1.8.0_144-b01)
OpenJDK 64-Bit Server VM (build 25.144-b01, mixed mode)

[org.clojure/clojure "1.9.0-beta1"]
[org.clojure/test.check "0.10.0-alpha2" :scope "test"]


Full code :

(ns myns.specs
  (:require [clojure.spec.alpha :as s]
[clojure.string :as str]
[clojure.test.check.generators :as g]))

(def url-path (g/fmap #(apply str "/" %) (g/vector g/char-alphanumeric 5 
10)))

(s/def :url/path (s/with-gen (s/and string? #(re-matches #"^(/.*)+" %))
 (fn path-gen []
   (g/fmap #(apply str %) (g/vector url-path 1 
3)


Generation fails :

(g/sample (s/gen :url/path) 3)
clojure.lang.ExceptionInfo: Couldn't satisfy such-that predicate after 100 
tries.



If I rename `:url/path` to `:url/path2` or `::path`, it works fine !

I tried searching the source code of spec to see if there was already a 
spec with the same name, but there was none. I have no idea where this 
problem comes from. Any help appreciated.

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

Re: Converting json to work with clojure.spec

[jmckitrick]

Hmm, that might be useful. I assume it would make sense for an API called
from other apps, but not so much for internal web services called from your
own client app.

On Mon, Aug 7, 2017 at 4:04 AM Peter Hull  wrote:

>
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/hfSq0gaeFAc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Jonathon McKitrick

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

[Peter Hull]

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.

Re: Converting json to work with clojure.spec

[Brian Scaturro]

Hi Jonathon,

I am trying to figure out the same thing. I am using all namespace 
qualified keys, but curious how this works when using s/conform on a json 
payload. Did you ever find a solution for this?

Thanks!
Brian

On Sunday, December 4, 2016 at 10:11:55 AM UTC-5, Jonathon McKitrick wrote:
>
> Ah, I see that now.
>
> 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?
>
> On Saturday, November 19, 2016 at 9:23:32 AM UTC-5, Alex Miller wrote:
>>
>> s/keys has :req-un and :opt-un alternatives for un-qualified keys.
>
>

-- 
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] inspectable 0.1.0 Improve your repl experience when using clojure.spec

[Juan Monetta]

What?

A couple of tools for Clojure to help you work with clojure.spec in the 
repl with the spirit of improving error
messages.

Where?

[inspectable "0.1.0"]
https://github.com/jpmonettas/inspectable

Summary?

Inspectable 0.1.0 contains two tools

- borwse-spec : A GUI spec registry browser.
- why : A GUI that explains spec fails in a bunch of different situations.

-- 
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: clojure.spec - Using :pre conditions (or not)?

[David Goldfarb]

Agreed; I was just following up on your previous comments.

But, it is useful to have something that can be used in a precondition and also 
shows an explanation.

I’m using, basically, (or (s/valid? spec x) (s/explain spec x)). It would be 
good to have this built-in too.

From: clojure@googlegroups.com [mailto:clojure@googlegroups.com] On Behalf Of 
Alex Miller
Sent: Wednesday, June 7, 2017 5:46 PM
To: Clojure <clojure@googlegroups.com>
Subject: Re: clojure.spec - Using :pre conditions (or not)?

Preconditions are already assertions, so it makes more sense to use s/assert in 
your code body than in a precondition.

On Wednesday, June 7, 2017 at 8:12:22 AM UTC-5, David Goldfarb wrote:
One big downside of using s/assert in a precondition:  It does not work with 
(s/nilable ...) specs, since s/assert returns valid values.

I fell into this trap for a moment of head-scratching just now.

On Wednesday, September 14, 2016 at 4:59:09 PM UTC+3, Alex Miller wrote:
Another option that has been added since the guide was written is s/assert 
which seems closer to what you're suggesting.

(defn name [user]
  {:pre [(s/assert :common/user user)]}
  (-> user :user/name))

;; need to enable assertion checking - this can also be enabled globally with 
system property clojure.spec.check-asserts
(s/check-asserts true)

(name {:user/name "Elon"})
"Elon"

(name {:x "Elon"})
ExceptionInfo Spec assertion failed
val: {:x "Elon"} fails predicate: (contains? % :user/name)
:clojure.spec/failure  :assertion-failed
  clojure.core/ex-info (core.clj:4725)

Rather than use it in a precondition, you can also use s/assert directly in the 
code.

On Wednesday, September 14, 2016 at 7:37:24 AM UTC-5, 
joakim.t...@nova.com<mailto:joakim.t...@nova.com> wrote:

(ns spec-test.core
  (:require [clojure.spec :as s]))

(s/def :user/name string?)
(s/def :common/user (s/keys :req [:user/name]))

; first version of name (using :pre)
(defn name [user]
  {:pre [(s/valid? :common/user user)]}
  (-> user :user/name))

; This statement works ok and returns "Elon":
(name {:user/name "Elon"})

; but this statement...
(name {:x "Elon"})

;...will throw:
CompilerException java.lang.AssertionError:
Assert failed: (s/valid? :common/user user)

; ...but then I don't get as much information
; about the error as if I would have called:
(s/explain :common/user {:x "Elon"})

;...which also contains the predicate:
val: {:x "Elon"} fails spec: :common/user
predicate: (contains? % :user/name)

; (second version of name - more verbose)
; or do I need to wite it like this:
(defn name [user]
  (let [parsed (s/conform :common/user user)]
(if (= parsed ::s/invalid)
  (throw (ex-info "Invalid input" (s/explain-data :common/user user)))
  (-> user :user/name

; so that:
(name {:x "Elon"})

; ...will return:
CompilerException clojure.lang.ExceptionInfo:
  Invalid input #:clojure.spec{:problems}
({:path [], :pred (contains? % :user/name),
  :val {:x "Elon"}, :via [:common/user], :in []})

; It should be nice if I could be able to write it like this
; (or similar, to get a better error message):
(defn name [user]
  {:pre [(s/explain :common/user user)]}
  (-> user :user/name))
--
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<mailto: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<mailto: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 a topic in the Google 
Groups "Clojure" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/clojure/H9tk04sSTWE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
clojure+unsubscr...@googlegroups.com<mailto: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.

Generated schemas with clojure.spec

[Petr]

Hello,

I tried to use clojure.spec for validation and test data generation of 
requests for API described according OpenAPI (https://www.openapis.org/).
My code reads an OpenAPI specification, then constructs description that 
can be used with clojure.spec. 
The idea was to validate a request map according to spec or generate 
request structure that conform this spec.

I tried to generate regexp-like clojure.spec expressions that use tuples 
where first item selects specification sub-tree. 
For example:

(alt
  path-1-key (tuple path-1 (alt method-1-1-key (tuple method-1-1 (cat 
..params..))
method-1-2-key (tuple method-1-2 (cat 
..params..
  path-2-key (tuple path-2 (alt method-2-1-key (tuple method-2-1 (cat 
..params..))
method-2-2-key (tuple method-2-2 (cat 
..params..)
(cat is used for parameters so I can describe optional ones with `?`)

My experiment code is here 
https://github.com/PetrGlad/oasiege/blob/master/src/oasiege/core.clj
The approach turned out to be cumbersome, since generated structure has 
different structure than result I want.

It looks like clojure.spec's requirement for fully qualified spec names is 
made in assumption that all specs will be hand-crafted.
My first idea was to generate top level spec for paths, then for methods 
and so on. That would require qualified spec names that describe map keys. 
But names from OpenAPI description are unqualified. So to generate map of 
request parameters {:param-a val-a} I should somehow to work 
around the need to have specs like :api-specs.generated.spec1.param-a that 
should eventually produce [:param-a val-a] key-value pair
("spec1" name part would be generated for each loaded OpenAPI 
specification). Also it is not clear what to do if I want non keyword map 
keys. 

So the question: is there a more straightforward way to work with 
specifications that are known only at run time or this is out of intended 
clojure.spec usage?

-- 
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: clojure.spec - Using :pre conditions (or not)?

[Alex Miller]

Preconditions are already assertions, so it makes more sense to use 
s/assert in your code body than in a precondition.

On Wednesday, June 7, 2017 at 8:12:22 AM UTC-5, David Goldfarb wrote:
>
> One big downside of using s/assert in a precondition:  It does not work 
> with (s/nilable ...) specs, since s/assert returns valid values.
>
> I fell into this trap for a moment of head-scratching just now.
>
> On Wednesday, September 14, 2016 at 4:59:09 PM UTC+3, Alex Miller wrote:
>>
>> Another option that has been added since the guide was written is 
>> s/assert which seems closer to what you're suggesting.
>>
>> (defn name [user]
>>   {:pre [(s/assert :common/user user)]}
>>   (-> user :user/name))
>>
>> ;; need to enable assertion checking - this can also be enabled globally 
>> with system property clojure.spec.check-asserts
>> (s/check-asserts true)
>>
>> (name {:user/name "Elon"})
>> "Elon"
>>
>> (name {:x "Elon"})
>> ExceptionInfo Spec assertion failed
>> val: {:x "Elon"} fails predicate: (contains? % :user/name)
>> :clojure.spec/failure  :assertion-failed
>>   clojure.core/ex-info (core.clj:4725)
>>
>> Rather than use it in a precondition, you can also use s/assert directly 
>> in the code.
>>
>> On Wednesday, September 14, 2016 at 7:37:24 AM UTC-5, 
>> joakim.t...@nova.com wrote:
>>>
>>> (ns spec-test.core
>>>   (:require [clojure.spec :as s]))
>>>
>>> (s/def :user/name string?)
>>> (s/def :common/user (s/keys :req [:user/name]))
>>>
>>> ; first version of name (using :pre)
>>> (defn name [user]
>>>   {:pre [(s/valid? :common/user user)]}
>>>   (-> user :user/name))
>>>
>>> ; This statement works ok and returns "Elon":
>>> (name {:user/name "Elon"})
>>>
>>> ; but this statement...
>>> (name {:x "Elon"})
>>>
>>> ;...will throw:
>>> CompilerException java.lang.AssertionError:
>>> Assert failed: (s/valid? :common/user user)
>>>
>>> ; ...but then I don't get as much information
>>> ; about the error as if I would have called:
>>> (s/explain :common/user {:x "Elon"})
>>>
>>> ;...which also contains the predicate:
>>> val: {:x "Elon"} fails spec: :common/user
>>> predicate: (contains? % :user/name)
>>>
>>> ; (second version of name - more verbose)
>>> ; or do I need to wite it like this:
>>> (defn name [user]
>>>   (let [parsed (s/conform :common/user user)]
>>> (if (= parsed ::s/invalid)
>>>   (throw (ex-info "Invalid input" (s/explain-data :common/user user)))
>>>   (-> user :user/name
>>>
>>> ; so that:
>>> (name {:x "Elon"})
>>>
>>> ; ...will return:
>>> CompilerException clojure.lang.ExceptionInfo:
>>>   Invalid input #:clojure.spec{:problems}
>>> ({:path [], :pred (contains? % :user/name),
>>>   :val {:x "Elon"}, :via [:common/user], :in []})
>>>
>>> ; It should be nice if I could be able to write it like this
>>> ; (or similar, to get a better error message):
>>> (defn name [user]
>>>   {:pre [(s/explain :common/user user)]}
>>>   (-> user :user/name))
>>>
>>>

-- 
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: clojure.spec - Using :pre conditions (or not)?

[David Goldfarb]

One big downside of using s/assert in a precondition:  It does not work 
with (s/nilable ...) specs, since s/assert returns valid values.

I fell into this trap for a moment of head-scratching just now.

On Wednesday, September 14, 2016 at 4:59:09 PM UTC+3, Alex Miller wrote:
>
> Another option that has been added since the guide was written is s/assert 
> which seems closer to what you're suggesting.
>
> (defn name [user]
>   {:pre [(s/assert :common/user user)]}
>   (-> user :user/name))
>
> ;; need to enable assertion checking - this can also be enabled globally 
> with system property clojure.spec.check-asserts
> (s/check-asserts true)
>
> (name {:user/name "Elon"})
> "Elon"
>
> (name {:x "Elon"})
> ExceptionInfo Spec assertion failed
> val: {:x "Elon"} fails predicate: (contains? % :user/name)
> :clojure.spec/failure  :assertion-failed
>   clojure.core/ex-info (core.clj:4725)
>
> Rather than use it in a precondition, you can also use s/assert directly 
> in the code.
>
> On Wednesday, September 14, 2016 at 7:37:24 AM UTC-5, joakim.t...@nova.com 
>  wrote:
>>
>> (ns spec-test.core
>>   (:require [clojure.spec :as s]))
>>
>> (s/def :user/name string?)
>> (s/def :common/user (s/keys :req [:user/name]))
>>
>> ; first version of name (using :pre)
>> (defn name [user]
>>   {:pre [(s/valid? :common/user user)]}
>>   (-> user :user/name))
>>
>> ; This statement works ok and returns "Elon":
>> (name {:user/name "Elon"})
>>
>> ; but this statement...
>> (name {:x "Elon"})
>>
>> ;...will throw:
>> CompilerException java.lang.AssertionError:
>> Assert failed: (s/valid? :common/user user)
>>
>> ; ...but then I don't get as much information
>> ; about the error as if I would have called:
>> (s/explain :common/user {:x "Elon"})
>>
>> ;...which also contains the predicate:
>> val: {:x "Elon"} fails spec: :common/user
>> predicate: (contains? % :user/name)
>>
>> ; (second version of name - more verbose)
>> ; or do I need to wite it like this:
>> (defn name [user]
>>   (let [parsed (s/conform :common/user user)]
>> (if (= parsed ::s/invalid)
>>   (throw (ex-info "Invalid input" (s/explain-data :common/user user)))
>>   (-> user :user/name
>>
>> ; so that:
>> (name {:x "Elon"})
>>
>> ; ...will return:
>> CompilerException clojure.lang.ExceptionInfo:
>>   Invalid input #:clojure.spec{:problems}
>> ({:path [], :pred (contains? % :user/name),
>>   :val {:x "Elon"}, :via [:common/user], :in []})
>>
>> ; It should be nice if I could be able to write it like this
>> ; (or similar, to get a better error message):
>> (defn name [user]
>>   {:pre [(s/explain :common/user user)]}
>>   (-> user :user/name))
>>
>>

-- 
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: clojure.spec merge+or bug?

[Alex Miller]

You can file a bug on the s/merge unform - anything that doesn't roundtrip 
should be a bug.

On the coll-of one, I thought that was just fixed in the latest spec.alpha 
release (see https://dev.clojure.org/jira/browse/CLJ-2076) - are you using 
latest there?

-- 
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: clojure.spec merge+or bug?

[Jenny Finkel]

It also seems to come up with coll-of + or:

user> (s/def ::a (s/or :even even? :odd odd?))
user> (s/def ::c (s/coll-of ::a))
user> (s/conform ::c [1 2 3 4])
[[:odd 1] [:even 2] [:odd 3] [:even 4]]
user> (s/unform ::c (s/conform ::c [1 2 3 4]))
[[:odd 1] [:even 2] [:odd 3] [:even 4]]

It looks like coll-of calls every-impl which just has identity as it's 
unform fn.
-Jenny

On Wednesday, May 31, 2017 at 9:37:43 PM UTC-7, Jenny Finkel wrote:
>
> I think I found a bug in spec when combining merge and or. Basically, when 
> you conform a map where one of the keys has an or, and the spec comes from 
> a clojure.spec/merge, one of the underlying keys will conform it, while the 
> others don't, and then when the results get merged together you can end up 
> with the unconformed version in the result:
>
> user> (require '[clojure.spec :as s])
> user> (s/def ::a (s/or :even even? :odd odd?))
> user> (s/def ::b (s/or :even even? :odd odd?))
> user> (s/def ::m1 (s/keys :req-un [::a]))
> user> (s/def ::m2 (s/keys :req-un [::b]))
> user> (s/def ::mm (s/merge ::m1 ::m2))
> user> (s/valid? ::mm {:a 1 :b 2})
> true
> user> (s/conform ::mm {:a 1 :b 2})
> {:a 1, :b [:even 2]}
> user> (s/unform ::mm {:a [:odd 1] :b [:even 2]})
> {:a 1, :b [:even 2]}
> user> (s/unform ::mm (s/conform ::mm {:a 1 :b 2}))
> UnsupportedOperationException nth not supported on this type: Long 
>  clojure.lang.RT.nthFrom (RT.java:962)
>
> I guess that valid? checks if it satisfies all the merged specs, and 
> conform conforms on each and merges, and then unform can end up with a 
> result that it can't unform (and similarly, if you give unform a properly 
> conformed thing it can't unform properly due to how it merges results as 
> well). I think the fix would be an update to clojure.spec/merge to make it 
> smarter about which keys to keep from each map on conforming and unforming, 
> though looking at the current code I don't think it's an easy fix.
>
> -Jenny
>

-- 
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: clojure.spec merge+or bug?

[Jenny Finkel]

thanks for the fast reply! do you think it will always be this way? it does
seem to violate the expected conform/unform relationship.

On Wed, May 31, 2017 at 9:51 PM, Alex Miller  wrote:

> This is actually the expected result. s/merge doesn't flow like s/and -
> only the conformed version of the last map spec in the merge is used. There
> are thus some unexpected results in combination with the -un options as
> they are the only link towards conforming.
>
> One thing you could try instead is to use s/and which does flow and might
> give you some of the behavior you're looking for (but won't gen as well).
>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/r8WO24rHsi0/unsubscribe.
> To unsubscribe from this group and all its topics, 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.

clojure.spec merge+or bug?

[Alex Miller]

This is actually the expected result. s/merge doesn't flow like s/and - only 
the conformed version of the last map spec in the merge is used. There are thus 
some unexpected results in combination with the -un options as they are the 
only link towards conforming.

One thing you could try instead is to use s/and which does flow and might give 
you some of the behavior you're looking for (but won't gen as well).

-- 
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: clojure.spec merge+or bug?

[Jenny Finkel]

PS - I just realize I wasn't using the latest version of spec, as is 
evident from my require, but I just tried again with the latest and it 
doesn't change the result. And I should have mentioned that I'm happy to 
take a stab at a fix, assuming I'm correct that this is a bug.

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

clojure.spec merge+or bug?

[Jenny Finkel]

I think I found a bug in spec when combining merge and or. Basically, when 
you conform a map where one of the keys has an or, and the spec comes from 
a clojure.spec/merge, one of the underlying keys will conform it, while the 
others don't, and then when the results get merged together you can end up 
with the unconformed version in the result:

user> (require '[clojure.spec :as s])
user> (s/def ::a (s/or :even even? :odd odd?))
user> (s/def ::b (s/or :even even? :odd odd?))
user> (s/def ::m1 (s/keys :req-un [::a]))
user> (s/def ::m2 (s/keys :req-un [::b]))
user> (s/def ::mm (s/merge ::m1 ::m2))
user> (s/valid? ::mm {:a 1 :b 2})
true
user> (s/conform ::mm {:a 1 :b 2})
{:a 1, :b [:even 2]}
user> (s/unform ::mm {:a [:odd 1] :b [:even 2]})
{:a 1, :b [:even 2]}
user> (s/unform ::mm (s/conform ::mm {:a 1 :b 2}))
UnsupportedOperationException nth not supported on this type: Long 
 clojure.lang.RT.nthFrom (RT.java:962)

I guess that valid? checks if it satisfies all the merged specs, and 
conform conforms on each and merges, and then unform can end up with a 
result that it can't unform (and similarly, if you give unform a properly 
conformed thing it can't unform properly due to how it merges results as 
well). I think the fix would be an update to clojure.spec/merge to make it 
smarter about which keys to keep from each map on conforming and unforming, 
though looking at the current code I don't think it's an easy fix.

-Jenny

-- 
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: [clojure.spec/form] Need for evaluated subspecs

[marian . hornak]

Thanks Alex,

I am surprised by info that *"s/and (and all of the spec forms) are macros 
to facilitate capturing the spec form for use in s/form and error 
reporting." *but everything makes sense considering it.

Marián

On Thursday, May 18, 2017 at 6:35:46 PM UTC+2, Alex Miller wrote:
>
>
>
> On Wednesday, May 17, 2017 at 3:02:17 PM UTC-5, marian...@vacuumlabs.com 
>  wrote:
>>
>> Hi,
>>
>> I am writing a function that transforms Specs to another formats (similar 
>> to the JSON Schema). Assuming from this post 
>> <http://www.metosin.fi/blog/clojure-spec-as-a-runtime-transformation-engine/>,
>>  
>> I am not the only one. There is no surprise that I am using 
>> clojure.spec/form. Unfortunately I am not fully satisfied with its 
>> output. To illustrate the problem let's suppose that my transformer will be 
>> used by a third person who like to write its own spec-generating helpers:
>>
>> (require '[clojure.spec.alpha :as spec])
>>
>> (spec/def ::forgivable-keyword (spec/conformer (fn [x] (cond (keyword? x) 
>> x
>>  (string? x) 
>> (keyword x)
>>  true 
>> ::spec/invalid
>>
>> (defn kw-enum [& enum-values] (spec/and ::forgivable-keyword (apply 
>> hash-set enum-values)))
>>
>>
> s/and (and all of the spec forms) are macros to facilitate capturing the 
> spec form for use in s/form and error reporting.
>
> In this case, (apply hash-set enum-values) is not either a predicate or a 
> set and thus is not a valid spec to use in s/and. 
>
> I presume what you're looking for is the ability to dynamically create 
> specs - for this, please consider using either eval or a macro.
>
>  
>
>> Cool! Let's look how can my transformer cope with it!
>>
>> (spec/form (kw-enum :a :b :c))
>> ; (clojure.spec.alpha/and 
>> :my-ns/forgivable-keyword (clojure.core/apply clojure.core/hash-set 
>> enum-values))
>>
>> Ouch! Have I just seen a local symbol in the form? I am sorry third 
>> person, I won't be able to transform the output of your spec-generating 
>> functions. Unless they are macros:
>>
>> (defmacro kw-enum [& enum-values] `(spec/and ::forgivable-keyword ~(apply 
>> hash-set enum-values)))
>>
>> (spec/form (kw-enum :a :b :c))
>> ; (clojure.spec.alpha/and :my-ns/forgivable-keyword #{:c :b :a})
>>
>> This approach looks better. How does it work in combination with other 
>> specs?
>>
>> (spec/form (spec/nilable (kw-enum :a :b :c)))
>> ; (clojure.spec.alpha/nilable (my-ns/kw-enum :a :b :c))
>>
>> There we are. A third-person's function is in the form. We could use eval to 
>> resolve it, but do we want to? 
>>
>
> Sure. It resolved to a spec last time, why not this time? OR, why do you 
> need to resolve it at all? (this to some degree depends on the use case)
>  
>
>> It has been already evaluated once. What if there are some side effects?
>>
>
> Then I'd say you already have more important problems.
>  
>
>> Practically, one has no option to write spec-generating function and 
>> maintain usability of the spec/form at the same time. Therefore one of 
>> four situations must have happened. Either I got something wrong, Specs are 
>> not meant to be introspected, Specs are not meant to be generated or 
>> spec/form is badly designed. Which one is it?
>>
>
> Seems to me like you can generate and introspect this fine. I think that 
> if you are introspecting spec forms, you will encounter resolved symbols 
> referring to functions. How you approach the use of those depends on your 
> context.
>
> Another option still coming (work in progress) is to use specs on spec 
> forms (CLJ-2112) to create conformed spec data, then s/unform back to a 
> spec form. 
>  
>
>>
>> (In the case of the fourth one I have some suggestions, but lets keep 
>> them for later conversation)
>>
>> Thanks for your time
>>
>> Marian
>>
>

-- 
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] Clojure 1.9 / clojure.spec split

[Matching Socks]

>   Additionally, this is a first step towards increased support for 
leveraging dependencies within Clojure.

What do you have in mind?

-- 
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: [clojure.spec/form] Need for evaluated subspecs

[Leon Grapenthin]

Hi Alex, thanks for replying. Indeed I don't have practical use for s/form 
right now; I'm just trying to guess what could be a good use in the future 
:) 

On Thursday, May 18, 2017 at 10:01:25 PM UTC+2, Alex Miller wrote:
>
>
>
> On Thursday, May 18, 2017 at 12:37:26 PM UTC-5, Leon Grapenthin wrote:
>>
>> I also have this problem. 
>>
>> 1. If I create a dynamic spec constructor per defmacro and invoke it, 
>> it's s/form gives the primitive specs form - because spec doesn't provide 
>> me with a way to facilitate specs that capture their form.
>>
>
> The idea of providing custom form serialization support is one I have 
> spent quite a bit of time looking at (in particular wrt s/&, s/keys*, and 
> the range specs, but in practice the same problem is being worked around in 
> the coll specs, etc). I've done spikes on three possible directions for 
> this and I can't say any of them is an unambiguous win so it's going to 
> require some Rich time at some point to make further decisions. In some 
> ways it's an analogous problem to how custom gens are implemented.
>  
>
>> 2. If I apply that invocation to another primitive spec, s/form of that 
>> just contains the macro invocation form.
>>
>> If this is intentional, I'd also like to know the underlying design rule 
>> (not the reasons why that is so in the current implementation): Why should 
>> this result in two different forms for one and the same spec to deal with, 
>> instead of one.
>>
>
> The principle is to capture the spec form at the time of construction for 
> the purposes of a) reporting and b) serialization via s/form. That seems 
> satisfied in both cases. 
>  
>
>> The reason to create "dynamic" spec constructors is usually to avoid 
>> boilerplate when writing specs. Unless I'm missing what I shouldn't do, I'd 
>> prefer to have direct support for that spares me having to deal with two 
>> forms.
>>
>
> In what way are you "dealing with" two forms? Why is that a problem?
>  
>
>>
>> Kind regards,
>>  Leon.
>>
>> On Thursday, May 18, 2017 at 6:35:46 PM UTC+2, Alex Miller wrote:
>>>
>>>
>>>
>>> On Wednesday, May 17, 2017 at 3:02:17 PM UTC-5, marian...@vacuumlabs.com 
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I am writing a function that transforms Specs to another formats 
>>>> (similar to the JSON Schema). Assuming from this post 
>>>> <http://www.metosin.fi/blog/clojure-spec-as-a-runtime-transformation-engine/>,
>>>>  
>>>> I am not the only one. There is no surprise that I am using 
>>>> clojure.spec/form. Unfortunately I am not fully satisfied with its 
>>>> output. To illustrate the problem let's suppose that my transformer will 
>>>> be 
>>>> used by a third person who like to write its own spec-generating helpers:
>>>>
>>>> (require '[clojure.spec.alpha :as spec])
>>>>
>>>> (spec/def ::forgivable-keyword (spec/conformer (fn [x] (cond (keyword? 
>>>> x) x
>>>>  (string? 
>>>> x) (keyword x)
>>>>  true 
>>>> ::spec/invalid
>>>>
>>>> (defn kw-enum [& enum-values] (spec/and ::forgivable-keyword (apply 
>>>> hash-set enum-values)))
>>>>
>>>>
>>> s/and (and all of the spec forms) are macros to facilitate capturing the 
>>> spec form for use in s/form and error reporting.
>>>
>>> In this case, (apply hash-set enum-values) is not either a predicate or 
>>> a set and thus is not a valid spec to use in s/and. 
>>>
>>> I presume what you're looking for is the ability to dynamically create 
>>> specs - for this, please consider using either eval or a macro.
>>>
>>>  
>>>
>>>> Cool! Let's look how can my transformer cope with it!
>>>>
>>>> (spec/form (kw-enum :a :b :c))
>>>> ; (clojure.spec.alpha/and 
>>>> :my-ns/forgivable-keyword (clojure.core/apply clojure.core/hash-set 
>>>> enum-values))
>>>>
>>>> Ouch! Have I just seen a local symbol in the form? I am sorry third 
>>>> person, I won't be able to transform the output of your spec-generating 
>>>> functions. Unless they are macros:
>>>>
>>>> (defmacro 
>>>> kw-enum [& enum-values] `(spec/and ::forgivable-keyword 

Re: [clojure.spec/form] Need for evaluated subspecs

[Alex Miller]

On Thursday, May 18, 2017 at 12:37:26 PM UTC-5, Leon Grapenthin wrote:
>
> I also have this problem. 
>
> 1. If I create a dynamic spec constructor per defmacro and invoke it, it's 
> s/form gives the primitive specs form - because spec doesn't provide me 
> with a way to facilitate specs that capture their form.
>

The idea of providing custom form serialization support is one I have spent 
quite a bit of time looking at (in particular wrt s/&, s/keys*, and the 
range specs, but in practice the same problem is being worked around in the 
coll specs, etc). I've done spikes on three possible directions for this 
and I can't say any of them is an unambiguous win so it's going to require 
some Rich time at some point to make further decisions. In some ways it's 
an analogous problem to how custom gens are implemented.
 

> 2. If I apply that invocation to another primitive spec, s/form of that 
> just contains the macro invocation form.
>
> If this is intentional, I'd also like to know the underlying design rule 
> (not the reasons why that is so in the current implementation): Why should 
> this result in two different forms for one and the same spec to deal with, 
> instead of one.
>

The principle is to capture the spec form at the time of construction for 
the purposes of a) reporting and b) serialization via s/form. That seems 
satisfied in both cases. 
 

> The reason to create "dynamic" spec constructors is usually to avoid 
> boilerplate when writing specs. Unless I'm missing what I shouldn't do, I'd 
> prefer to have direct support for that spares me having to deal with two 
> forms.
>

In what way are you "dealing with" two forms? Why is that a problem?
 

>
> Kind regards,
>  Leon.
>
> On Thursday, May 18, 2017 at 6:35:46 PM UTC+2, Alex Miller wrote:
>>
>>
>>
>> On Wednesday, May 17, 2017 at 3:02:17 PM UTC-5, marian...@vacuumlabs.com 
>> wrote:
>>>
>>> Hi,
>>>
>>> I am writing a function that transforms Specs to another formats 
>>> (similar to the JSON Schema). Assuming from this post 
>>> <http://www.metosin.fi/blog/clojure-spec-as-a-runtime-transformation-engine/>,
>>>  
>>> I am not the only one. There is no surprise that I am using 
>>> clojure.spec/form. Unfortunately I am not fully satisfied with its 
>>> output. To illustrate the problem let's suppose that my transformer will be 
>>> used by a third person who like to write its own spec-generating helpers:
>>>
>>> (require '[clojure.spec.alpha :as spec])
>>>
>>> (spec/def ::forgivable-keyword (spec/conformer (fn [x] (cond (keyword? 
>>> x) x
>>>  (string? x) 
>>> (keyword x)
>>>  true 
>>> ::spec/invalid
>>>
>>> (defn kw-enum [& enum-values] (spec/and ::forgivable-keyword (apply 
>>> hash-set enum-values)))
>>>
>>>
>> s/and (and all of the spec forms) are macros to facilitate capturing the 
>> spec form for use in s/form and error reporting.
>>
>> In this case, (apply hash-set enum-values) is not either a predicate or a 
>> set and thus is not a valid spec to use in s/and. 
>>
>> I presume what you're looking for is the ability to dynamically create 
>> specs - for this, please consider using either eval or a macro.
>>
>>  
>>
>>> Cool! Let's look how can my transformer cope with it!
>>>
>>> (spec/form (kw-enum :a :b :c))
>>> ; (clojure.spec.alpha/and 
>>> :my-ns/forgivable-keyword (clojure.core/apply clojure.core/hash-set 
>>> enum-values))
>>>
>>> Ouch! Have I just seen a local symbol in the form? I am sorry third 
>>> person, I won't be able to transform the output of your spec-generating 
>>> functions. Unless they are macros:
>>>
>>> (defmacro 
>>> kw-enum [& enum-values] `(spec/and ::forgivable-keyword ~(apply 
>>> hash-set enum-values)))
>>>
>>> (spec/form (kw-enum :a :b :c))
>>> ; (clojure.spec.alpha/and :my-ns/forgivable-keyword #{:c :b :a})
>>>
>>> This approach looks better. How does it work in combination with other 
>>> specs?
>>>
>>> (spec/form (spec/nilable (kw-enum :a :b :c)))
>>> ; (clojure.spec.alpha/nilable (my-ns/kw-enum :a :b :c))
>>>
>>> There we are. A third-person's function is in the form. We could use 
>>> eval to resolve it, but do we want to? 
>>>
>>
>> Sure. It resolved to a spec last time, why no

Re: [clojure.spec/form] Need for evaluated subspecs

[Leon Grapenthin]

I also have this problem. 

1. If I create a dynamic spec constructor per defmacro and invoke it, it's 
s/form gives the primitive specs form - because spec doesn't provide me 
with a way to facilitate specs that capture their form.

2. If I apply that invocation to another primitive spec, s/form of that 
just contains the macro invocation form.

If this is intentional, I'd also like to know the underlying design rule 
(not the reasons why that is so in the current implementation): Why should 
this result in two different forms for one and the same spec to deal with, 
instead of one.

The reason to create "dynamic" spec constructors is usually to avoid 
boilerplate when writing specs. Unless I'm missing what I shouldn't do, I'd 
prefer to have direct support for that spares me having to deal with two 
forms.

Kind regards,
 Leon.

On Thursday, May 18, 2017 at 6:35:46 PM UTC+2, Alex Miller wrote:
>
>
>
> On Wednesday, May 17, 2017 at 3:02:17 PM UTC-5, marian...@vacuumlabs.com 
>  wrote:
>>
>> Hi,
>>
>> I am writing a function that transforms Specs to another formats (similar 
>> to the JSON Schema). Assuming from this post 
>> <http://www.metosin.fi/blog/clojure-spec-as-a-runtime-transformation-engine/>,
>>  
>> I am not the only one. There is no surprise that I am using 
>> clojure.spec/form. Unfortunately I am not fully satisfied with its 
>> output. To illustrate the problem let's suppose that my transformer will be 
>> used by a third person who like to write its own spec-generating helpers:
>>
>> (require '[clojure.spec.alpha :as spec])
>>
>> (spec/def ::forgivable-keyword (spec/conformer (fn [x] (cond (keyword? x) 
>> x
>>  (string? x) 
>> (keyword x)
>>  true 
>> ::spec/invalid
>>
>> (defn kw-enum [& enum-values] (spec/and ::forgivable-keyword (apply 
>> hash-set enum-values)))
>>
>>
> s/and (and all of the spec forms) are macros to facilitate capturing the 
> spec form for use in s/form and error reporting.
>
> In this case, (apply hash-set enum-values) is not either a predicate or a 
> set and thus is not a valid spec to use in s/and. 
>
> I presume what you're looking for is the ability to dynamically create 
> specs - for this, please consider using either eval or a macro.
>
>  
>
>> Cool! Let's look how can my transformer cope with it!
>>
>> (spec/form (kw-enum :a :b :c))
>> ; (clojure.spec.alpha/and 
>> :my-ns/forgivable-keyword (clojure.core/apply clojure.core/hash-set 
>> enum-values))
>>
>> Ouch! Have I just seen a local symbol in the form? I am sorry third 
>> person, I won't be able to transform the output of your spec-generating 
>> functions. Unless they are macros:
>>
>> (defmacro kw-enum [& enum-values] `(spec/and ::forgivable-keyword ~(apply 
>> hash-set enum-values)))
>>
>> (spec/form (kw-enum :a :b :c))
>> ; (clojure.spec.alpha/and :my-ns/forgivable-keyword #{:c :b :a})
>>
>> This approach looks better. How does it work in combination with other 
>> specs?
>>
>> (spec/form (spec/nilable (kw-enum :a :b :c)))
>> ; (clojure.spec.alpha/nilable (my-ns/kw-enum :a :b :c))
>>
>> There we are. A third-person's function is in the form. We could use eval to 
>> resolve it, but do we want to? 
>>
>
> Sure. It resolved to a spec last time, why not this time? OR, why do you 
> need to resolve it at all? (this to some degree depends on the use case)
>  
>
>> It has been already evaluated once. What if there are some side effects?
>>
>
> Then I'd say you already have more important problems.
>  
>
>> Practically, one has no option to write spec-generating function and 
>> maintain usability of the spec/form at the same time. Therefore one of 
>> four situations must have happened. Either I got something wrong, Specs are 
>> not meant to be introspected, Specs are not meant to be generated or 
>> spec/form is badly designed. Which one is it?
>>
>
> Seems to me like you can generate and introspect this fine. I think that 
> if you are introspecting spec forms, you will encounter resolved symbols 
> referring to functions. How you approach the use of those depends on your 
> context.
>
> Another option still coming (work in progress) is to use specs on spec 
> forms (CLJ-2112) to create conformed spec data, then s/unform back to a 
> spec form. 
>  
>
>>
>> (In the case of the fourth one I have some suggestions, but lets keep 
>> them for later conversation)
>>
>

Re: [clojure.spec/form] Need for evaluated subspecs

[Alex Miller]

On Wednesday, May 17, 2017 at 3:02:17 PM UTC-5, 
marian.hor...@vacuumlabs.com wrote:
>
> Hi,
>
> I am writing a function that transforms Specs to another formats (similar 
> to the JSON Schema). Assuming from this post 
> <http://www.metosin.fi/blog/clojure-spec-as-a-runtime-transformation-engine/>,
>  
> I am not the only one. There is no surprise that I am using 
> clojure.spec/form. Unfortunately I am not fully satisfied with its 
> output. To illustrate the problem let's suppose that my transformer will be 
> used by a third person who like to write its own spec-generating helpers:
>
> (require '[clojure.spec.alpha :as spec])
>
> (spec/def ::forgivable-keyword (spec/conformer (fn [x] (cond (keyword? x) x
>  (string? x) 
> (keyword x)
>  true 
> ::spec/invalid
>
> (defn kw-enum [& enum-values] (spec/and ::forgivable-keyword (apply 
> hash-set enum-values)))
>
>
s/and (and all of the spec forms) are macros to facilitate capturing the 
spec form for use in s/form and error reporting.

In this case, (apply hash-set enum-values) is not either a predicate or a 
set and thus is not a valid spec to use in s/and. 

I presume what you're looking for is the ability to dynamically create 
specs - for this, please consider using either eval or a macro.

 

> Cool! Let's look how can my transformer cope with it!
>
> (spec/form (kw-enum :a :b :c))
> ; (clojure.spec.alpha/and 
> :my-ns/forgivable-keyword (clojure.core/apply clojure.core/hash-set 
> enum-values))
>
> Ouch! Have I just seen a local symbol in the form? I am sorry third 
> person, I won't be able to transform the output of your spec-generating 
> functions. Unless they are macros:
>
> (defmacro kw-enum [& enum-values] `(spec/and ::forgivable-keyword ~(apply 
> hash-set enum-values)))
>
> (spec/form (kw-enum :a :b :c))
> ; (clojure.spec.alpha/and :my-ns/forgivable-keyword #{:c :b :a})
>
> This approach looks better. How does it work in combination with other 
> specs?
>
> (spec/form (spec/nilable (kw-enum :a :b :c)))
> ; (clojure.spec.alpha/nilable (my-ns/kw-enum :a :b :c))
>
> There we are. A third-person's function is in the form. We could use eval to 
> resolve it, but do we want to? 
>

Sure. It resolved to a spec last time, why not this time? OR, why do you 
need to resolve it at all? (this to some degree depends on the use case)
 

> It has been already evaluated once. What if there are some side effects?
>

Then I'd say you already have more important problems.
 

> Practically, one has no option to write spec-generating function and 
> maintain usability of the spec/form at the same time. Therefore one of 
> four situations must have happened. Either I got something wrong, Specs are 
> not meant to be introspected, Specs are not meant to be generated or 
> spec/form is badly designed. Which one is it?
>

Seems to me like you can generate and introspect this fine. I think that if 
you are introspecting spec forms, you will encounter resolved symbols 
referring to functions. How you approach the use of those depends on your 
context.

Another option still coming (work in progress) is to use specs on spec 
forms (CLJ-2112) to create conformed spec data, then s/unform back to a 
spec form. 
 

>
> (In the case of the fourth one I have some suggestions, but lets keep them 
> for later conversation)
>
> Thanks for your time
>
> Marian
>

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

[clojure.spec/form] Need for evaluated subspecs

[marian . hornak]

Hi,

I am writing a function that transforms Specs to another formats (similar 
to the JSON Schema). Assuming from this post 
<http://www.metosin.fi/blog/clojure-spec-as-a-runtime-transformation-engine/>, 
I am not the only one. There is no surprise that I am using 
clojure.spec/form. Unfortunately I am not fully satisfied with its 
output. To illustrate the problem let's suppose that my transformer will be 
used by a third person who like to write its own spec-generating helpers:

(require '[clojure.spec.alpha :as spec])

(spec/def ::forgivable-keyword (spec/conformer (fn [x] (cond (keyword? x) x
 (string? x) 
(keyword x)
 true 
::spec/invalid

(defn kw-enum [& enum-values] (spec/and ::forgivable-keyword (apply 
hash-set enum-values)))

Cool! Let's look how can my transformer cope with it!

(spec/form (kw-enum :a :b :c))
; (clojure.spec.alpha/and :my-ns/forgivable-keyword (clojure.core/apply 
clojure.core/hash-set enum-values))

Ouch! Have I just seen a local symbol in the form? I am sorry third person, 
I won't be able to transform the output of your spec-generating functions. 
Unless they are macros:

(defmacro kw-enum [& enum-values] `(spec/and ::forgivable-keyword ~(apply 
hash-set enum-values)))

(spec/form (kw-enum :a :b :c))
; (clojure.spec.alpha/and :my-ns/forgivable-keyword #{:c :b :a})

This approach looks better. How does it work in combination with other 
specs?

(spec/form (spec/nilable (kw-enum :a :b :c)))
; (clojure.spec.alpha/nilable (my-ns/kw-enum :a :b :c))

There we are. A third-person's function is in the form. We could use eval to 
resolve it, but do we want to? It has been already evaluated once. What if 
there are some side effects?

Practically, one has no option to write spec-generating function and 
maintain usability of the spec/form at the same time. Therefore one of four 
situations must have happened. Either I got something wrong, Specs are not 
meant to be introspected, Specs are not meant to be generated or spec/form 
is badly designed. Which one is it?

(In the case of the fourth one I have some suggestions, but lets keep them 
for later conversation)

Thanks for your time

Marian

-- 
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: Clojure.spec: need function equivalents of library macros?

[Alex Miller]

On Tuesday, May 9, 2017 at 6:21:29 AM UTC-5, Dave Tenny wrote:
>
> My issues aren't about qualified or unqualified keys (and the APIs 
> generally need to accept unqualified keys - I do use qualified keys in 
> various contexts, just not this post where the topic is macros vs. 
> non-macro forms).
>

spec pushes you towards qualified keys for good reasons (see Rich's 
original rationale), so I don't expect that we'll be adding more support 
for unqualified keys. The support that is there is intended as a bridge 
towards qualified keys.
 

> s/merge is a good point about composition.  However often all I really 
> want to do is take some list of, say, keywords, acceptable in a map or 
> collection that is a parameter, and 'disj' one keyword from it for another 
> spec because that particular keyword isn't valid or supported for an 
> interface in question.
>

I have found that when I'm seeing this a lot, either the code is not 
modeling the domain well by not factoring common attributes OR my domain 
structures are actually very dynamic and have many optional attributes that 
can occur in any combination. In the former case, I can usually step back 
and refactor the code so that attributes that are always grouped together 
have their own unit and functions. 

In the latter case, the key is often to spec less. Instead of trying to 
identify every attribute on every function input and output, just create a 
single map spec with all of the optional attributes. You can then constrain 
it further if needed by doing (s/merge ::common (s/keys :req [::foo 
::bar])) if needed.

Or another approach is to just use (s/keys) to validate all the attributes 
that happen to be in a map flowing through a function. This is exactly the 
use case that spec makes possible that few other validation approaches can 
handle well (the case of checking arbitrary attributes flowing through a 
system) and its enabled by the use of qualified names with global semantics.

At the end of the day, I feel I'm often forced to cut and paste too many 
> similar but different lists into various specs (fdef in particular).  The 
> ability to construct specs without macros might be useful.  
>

We don't have them available yet, but we will have specs for spec forms 
(see CLJ-2112). With specs for spec forms, you can programmatically 
transform or construct maps in this way. With spec forms, you can start 
from a spec, s/conform to data, manipulate that data in any way you like, 
then s/unform back to a spec. You can also start in the middle and 
construct the conformed data version of a spec and s/unform to the list 
form.

 

-- 
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: Clojure.spec: need function equivalents of library macros?

[Dave Tenny]

My issues aren't about qualified or unqualified keys (and the APIs
generally need to accept unqualified keys - I do use qualified keys in
various contexts, just not this post where the topic is macros vs.
non-macro forms).

s/merge is a good point about composition.  However often all I really want
to do is take some list of, say, keywords, acceptable in a map or
collection that is a parameter, and 'disj' one keyword from it for another
spec because that particular keyword isn't valid or supported for an
interface in question.

At the end of the day, I feel I'm often forced to cut and paste too many
similar but different lists into various specs (fdef in particular).  The
ability to construct specs without macros might be useful.

On Tue, May 9, 2017 at 6:05 AM, Alex Miller  wrote:

> Is there any reason why you're using unqualified keys? If you're using
> qualified keys, then a simple (s/keys) spec will validate all registered
> keys in the map so you can cover all of your optional attribute cases that
> way.
>
> Another possibility worth mentioning is using s/merge to combine
> well-known (smaller) map specs into larger combinations.
>
>
> On Monday, May 8, 2017 at 10:38:34 AM UTC-5, Dave Tenny wrote:
>>
>> Let's say I have a namespace that provides access to the database,
>> say our table has these fields (as clojure specs)
>>
>> (s/def ::job-id nat-int?) ; 1 2 3 ...
>> (s/def ::job-name string?) ; frobozz-executor
>> (s/def ::job-status keyword?) ; :queued, :in-progress, :completed
>>
>>
>> And that I have the logic in place to convert to/from the types (e.g.
>> keywords).
>>
>> If I have a simple function to return records in from the jobs table it
>> might look like:
>>
>> (s/def ::job-record (s/keys :req-un [::job-id ::job-name ::job-status]))
>>
>> (s/fdef get-jobs
>>   :args (s/cat :db database-handle?)
>>   :ret (s/coll-of ::job-record))
>>
>> (defn get-jobs
>>   [db]
>>   ... returns vector of maps, one for each record, jdbc-style ...)
>>
>> (get-jobs) => [{:job-id 1 :job-name "frobozz-executor" :job-status
>> :queued} ...]
>>
>> Now here's where things get iffy in practice.  Suppose I have other
>> database interfaces that take similar but different maps or collections of
>> keywords.
>>
>> For example, a function like:
>>
>> (s/fdef get-selective-jobs
>>   :args (s/cat :db database-handle? :fields (s/keys :opt-un [::job-id
>> ::job-name ::job-status])))
>>
>> (defn get-selective-jobs
>>   [db fields]
>>   ... return only fields from the database that are specified in the
>> fields parameter ...)
>>
>>
>> Once you start getting some similar-but-different specs, it'd be nice
>> apply a bit of code building.
>>
>> e.g.
>>
>> (def job-field-keys [::job-id ::job-name ::job-status])
>>
>> (s/def ::job-record (s/keys* :req-un job-field-keys))
>> (s/fdef get-selective-args
>>   :args (s/cat* :db database-handle? :fields  (s/keys :opt-un
>> job-field-keys))
>>
>> Hopefully this is conducive to some thought/discussion of the subject,
>> and/or someone can just let me know how I should be doing this if there's
>> an easy way in the present spec implementation.
>>
>> Sidewise plea: inline specs for s/keys like you can do for s/cat.  s/keys
>> deliberate omision of inline specs does occasionally get in the way in
>> large namespaces.
>>
>>
>>
>> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/OBbq-jInyqI/unsubscribe.
> To unsubscribe from this group and all its topics, 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: Clojure.spec: need function equivalents of library macros?

[Alex Miller]

Is there any reason why you're using unqualified keys? If you're using 
qualified keys, then a simple (s/keys) spec will validate all registered 
keys in the map so you can cover all of your optional attribute cases that 
way.

Another possibility worth mentioning is using s/merge to combine well-known 
(smaller) map specs into larger combinations.


On Monday, May 8, 2017 at 10:38:34 AM UTC-5, Dave Tenny wrote:
>
> Let's say I have a namespace that provides access to the database,
> say our table has these fields (as clojure specs)
>
> (s/def ::job-id nat-int?) ; 1 2 3 ...
> (s/def ::job-name string?) ; frobozz-executor
> (s/def ::job-status keyword?) ; :queued, :in-progress, :completed
>
>
> And that I have the logic in place to convert to/from the types (e.g. 
> keywords).
>
> If I have a simple function to return records in from the jobs table it 
> might look like:
>
> (s/def ::job-record (s/keys :req-un [::job-id ::job-name ::job-status]))
>
> (s/fdef get-jobs
>   :args (s/cat :db database-handle?)
>   :ret (s/coll-of ::job-record))
>
> (defn get-jobs
>   [db]
>   ... returns vector of maps, one for each record, jdbc-style ...)
>
> (get-jobs) => [{:job-id 1 :job-name "frobozz-executor" :job-status 
> :queued} ...]
>
> Now here's where things get iffy in practice.  Suppose I have other 
> database interfaces that take similar but different maps or collections of 
> keywords.
>
> For example, a function like:
>
> (s/fdef get-selective-jobs
>   :args (s/cat :db database-handle? :fields (s/keys :opt-un [::job-id 
> ::job-name ::job-status])))
>
> (defn get-selective-jobs
>   [db fields]
>   ... return only fields from the database that are specified in the 
> fields parameter ...)
>
>
> Once you start getting some similar-but-different specs, it'd be nice 
> apply a bit of code building.
>
> e.g.
>
> (def job-field-keys [::job-id ::job-name ::job-status])
>
> (s/def ::job-record (s/keys* :req-un job-field-keys))
> (s/fdef get-selective-args
>   :args (s/cat* :db database-handle? :fields  (s/keys :opt-un 
> job-field-keys))
>
> Hopefully this is conducive to some thought/discussion of the subject, 
> and/or someone can just let me know how I should be doing this if there's 
> an easy way in the present spec implementation.
>
> Sidewise plea: inline specs for s/keys like you can do for s/cat.  s/keys 
> deliberate omision of inline specs does occasionally get in the way in 
> large namespaces.
>   
>
>
>

-- 
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: Clojure.spec: need function equivalents of library macros?

[Dave Tenny]

Oops, some corrections to my original post.

On Monday, May 8, 2017 at 11:38:34 AM UTC-4, Dave Tenny wrote:
>
> Let's say I have a namespace that provides access to the database,
> say our table has these fields (as clojure specs)
>
> (s/def ::job-id nat-int?) ; 1 2 3 ...
> (s/def ::job-name string?) ; frobozz-executor
> (s/def ::job-status keyword?) ; :queued, :in-progress, :completed
>
>
> And that I have the logic in place to convert to/from the types (e.g. 
> keywords).
>
> If I have a simple function to return records in from the jobs table it 
> might look like:
>
> (s/def ::job-record (s/keys :req-un [::job-id ::job-name ::job-status]))
>
> (s/fdef get-jobs
>   :args (s/cat :db database-handle?)
>   :ret (s/coll-of ::job-record))
>
> (defn get-jobs
>   [db]
>   ... returns vector of maps, one for each record, jdbc-style ...)
>
> (get-jobs) => [{:job-id 1 :job-name "frobozz-executor" :job-status 
> :queued} ...]
>
> Now here's where things get iffy in practice.  Suppose I have other 
> database interfaces that take similar but different maps or collections of 
> keywords.
>
> For example, a function like this which lets you specify which fields you 
> want retrieved:
>
> (s/fdef get-selective-jobs
>   :args (s/cat :db database-handle? :fields (s/coll-of #{:job-id :job-name 
> :job-status}))
>
  :ret (s/coll-of (s/keys :opt-un [ ::job-id ::job-name ::job-status 
])))

^^ correction of :fields above, additiobn of :ret


> (defn get-selective-jobs
>   [db fields]
>   ... return only fields from the database that are specified in the 
> fields parameter ...)
>
>
> Once you start getting some similar-but-different specs, it'd be nice 
> apply a bit of code building.
>
> e.g.
>
> (def job-field-keys [::job-id ::job-name ::job-status])
>
> (s/def ::job-record (s/keys* :req-un job-field-keys))
> (s/fdef get-selective-args
>   :args (s/cat* :db database-handle? :fields  (s/coll-of (set 
> job-field-keys))
>
:ret (s/coll-of (s/keys* :opt-un job-field-keys)))

^^ correction to :args above, addition of :ret


> Hopefully this is conducive to some thought/discussion of the subject, 
> and/or someone can just let me know how I should be doing this if there's 
> an easy way in the present spec implementation.
>

The point being that it's be nice to have some easier ways of specifying 
similar but different sets of data in
s/keys, s/cat, s/coll-of, and possibly other macros.

 

>
> Sidewise plea: inline specs for s/keys like you can do for s/cat.  s/keys 
> deliberate omision of inline specs does occasionally get in the way in 
> large namespaces.
>   
>
>
>

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

Clojure.spec: need function equivalents of library macros?

[Dave Tenny]

Let's say I have a namespace that provides access to the database,
say our table has these fields (as clojure specs)

(s/def ::job-id nat-int?) ; 1 2 3 ...
(s/def ::job-name string?) ; frobozz-executor
(s/def ::job-status keyword?) ; :queued, :in-progress, :completed


And that I have the logic in place to convert to/from the types (e.g. 
keywords).

If I have a simple function to return records in from the jobs table it 
might look like:

(s/def ::job-record (s/keys :req-un [::job-id ::job-name ::job-status]))

(s/fdef get-jobs
  :args (s/cat :db database-handle?)
  :ret (s/coll-of ::job-record))

(defn get-jobs
  [db]
  ... returns vector of maps, one for each record, jdbc-style ...)

(get-jobs) => [{:job-id 1 :job-name "frobozz-executor" :job-status :queued} 
...]

Now here's where things get iffy in practice.  Suppose I have other 
database interfaces that take similar but different maps or collections of 
keywords.

For example, a function like:

(s/fdef get-selective-jobs
  :args (s/cat :db database-handle? :fields (s/keys :opt-un [::job-id 
::job-name ::job-status])))

(defn get-selective-jobs
  [db fields]
  ... return only fields from the database that are specified in the fields 
parameter ...)


Once you start getting some similar-but-different specs, it'd be nice apply 
a bit of code building.

e.g.

(def job-field-keys [::job-id ::job-name ::job-status])

(s/def ::job-record (s/keys* :req-un job-field-keys))
(s/fdef get-selective-args
  :args (s/cat* :db database-handle? :fields  (s/keys :opt-un 
job-field-keys))

Hopefully this is conducive to some thought/discussion of the subject, 
and/or someone can just let me know how I should be doing this if there's 
an easy way in the present spec implementation.

Sidewise plea: inline specs for s/keys like you can do for s/cat.  s/keys 
deliberate omision of inline specs does occasionally get in the way in 
large namespaces.
  


-- 
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] Clojure 1.9 / clojure.spec split

[Steve Miner]

> On May 3, 2017, at 7:37 PM, Alex Miller  wrote:
> 
> A newer version (0.1.108) of spec.alpha is available that fixes the issue. 
> Note that this kind of update is exactly why the jars are split - you can 
> update the libs more frequently than the Clojure version.

Thanks. The updated spec.alpha works for me.

-- 
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] Clojure 1.9 / clojure.spec split

[Alex Miller]

Going forward, you will need to create your classpath with three jars: Clojure, 
spec.alpha, and core.specs.alpha. There are some more things planned in this 
area still to come. We do not currently plan to build a combined jar but things 
may change. The web page in question will be updated when 1.9 releases.

The error you are seeing with doc is a known issue due to spec.alpha not being 
aot compiled. A newer version (0.1.108) of spec.alpha is available that fixes 
the issue. Note that this kind of update is exactly why the jars are split - 
you can update the libs more frequently than the Clojure version.

-- 
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] Clojure 1.9 / clojure.spec split

[Steve Miner]

Before the spec split, the basic way to invoke Clojure at the command line was:

% java -cp clojure.jar clojure.main

Documented here: https://clojure.org/guides/getting_started 


Is that still the intended usage with 1.9 going forward?

When I try it with 1.9-alpha16, I get an error:

Exception in thread "main" java.lang.ExceptionInInitializerError
at clojure.main.(main.java:20)
Caused by: java.io.FileNotFoundException: Could not locate 
clojure/spec/alpha__init.class or clojure/spec/alpha.clj on classpath.

As a work-around, I grabbed the spec jars and added them to the classpath.  
That worked to get me to the REPL.

However, I noticed that I get an error from the doc function.  So something is 
still not right with spec.

% java -cp clojure.jar:spec.alpha-0.1.94.jar:core.specs.alpha-0.1.10.jar 
clojure.main
Clojure 1.9.0-alpha16
user=> (doc +)
-
clojure.core/+
([] [x] [x y] [x y & more])
  Returns the sum of nums. (+) returns 0. Does not auto-promote
  longs, will throw on overflow. See also: +'
ClassNotFoundException clojure.spec.alpha$get_spec  
java.net.URLClassLoader.findClass (URLClassLoader.java:381)

user=> *e
#error {
 :cause "clojure.spec.alpha$get_spec"
 :via
 [{:type java.lang.NoClassDefFoundError
   :message "clojure/spec/alpha$get_spec"
   :at [clojure.repl$print_doc invokeStatic "repl.clj" 109]}
  {:type java.lang.ClassNotFoundException
   :message "clojure.spec.alpha$get_spec"
   :at [java.net.URLClassLoader findClass "URLClassLoader.java" 381]}]
 :trace
 [[java.net.URLClassLoader findClass "URLClassLoader.java" 381]
  [java.lang.ClassLoader loadClass "ClassLoader.java" 424]
  [sun.misc.Launcher$AppClassLoader loadClass "Launcher.java" 331]
  [java.lang.ClassLoader loadClass "ClassLoader.java" 357]
  [clojure.repl$print_doc invokeStatic "repl.clj" 109]
  [clojure.repl$print_doc invoke "repl.clj" 83]
  [clojure.lang.Var invoke "Var.java" 381]
  [user$eval1596 invokeStatic "NO_SOURCE_FILE" 1]
  [user$eval1596 invoke "NO_SOURCE_FILE" 1]
  [clojure.lang.Compiler eval "Compiler.java" 6977]
  [clojure.lang.Compiler eval "Compiler.java" 6940]
  [clojure.core$eval invokeStatic "core.clj" 3187]
  [clojure.core$eval invoke "core.clj" 3183]
  [clojure.main$repl$read_eval_print__9835$fn__9838 invoke "main.clj" 242]
  [clojure.main$repl$read_eval_print__9835 invoke "main.clj" 242]
  [clojure.main$repl$fn__9844 invoke "main.clj" 260]
  [clojure.main$repl invokeStatic "main.clj" 260]
  [clojure.main$repl_opt invokeStatic "main.clj" 324]
  [clojure.main$main invokeStatic "main.clj" 423]
  [clojure.main$main doInvoke "main.clj" 386]
  [clojure.lang.RestFn invoke "RestFn.java" 397]
  [clojure.lang.AFn applyToHelper "AFn.java" 152]
  [clojure.lang.RestFn applyTo "RestFn.java" 132]
  [clojure.lang.Var applyTo "Var.java" 702]
  [clojure.main main "main.java" 37]]}


I think it would be nice to have an inclusive jar as before.  Or we could make 
Clojure 1.9 tolerant of not having spec available, perhaps by stubbing out the 
basics of spec.  Maybe give a warning that explains how to get the spec jars.

Steve Miner


-- 
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] Clojure 1.9 / clojure.spec split

[Alex Miller]

On Thursday, April 27, 2017 at 3:05:26 AM UTC-5, Tamas Herman wrote:
>
> What problems would it pose if the alpha status would be reflected in the 
> version number of org.clojure/spec,
> just like it is the case with org.clojure/clojure rightnow, which is 
> 1.9.0-alpha15?
>

At some future point, there will be a non-alpha version of spec. At that 
point it is effectively (and likely actually) a different library. Marking 
this one explicitly as alpha allows it to continue to exist and be in use 
by alpha users without a breaking change. Non-alpha users can switch to a 
new library with new namespaces.
 

> I've seen the Spec-ulation Keynote from Rich and this step feels like an 
> experiment
> to try out the idea of encoding the api version of a library in the name 
> of the library.
> Is that correct?
>

Kind of, but this is a little different in that we're talking about alpha 
(breaking change possible) vs non-alpha here.

-- 
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] Clojure 1.9 / clojure.spec split

[Tamas Herman]

What problems would it pose if the alpha status would be reflected in the 
version number of org.clojure/spec,
just like it is the case with org.clojure/clojure rightnow, which is 
1.9.0-alpha15?

I've seen the Spec-ulation Keynote from Rich and this step feels like an 
experiment
to try out the idea of encoding the api version of a library in the name of 
the library.
Is that correct?

-- 
  tom

-- 
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] Clojure 1.9 / clojure.spec split

[Sean Corfield]

I switched the World Singles’ codebase over to using org.clojure/spec.alpha 
today with no problems. Since we always `:require .. :as` it was an easy global 
find’n’replace (well, three of them – one for each namespace change needed). 
We’re also explicitly depending on the 0.1.94 release (so our build system will 
automatically track when a new version appears and flag that for us).

 

What would be the use case for users to explicitly depend on core.specs.alpha 
given that is only used internally by Clojure?

 

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

 

On 4/26/17, 6:02 PM, "Alex Miller" <clojure@googlegroups.com on behalf of 
a...@puredanger.com> wrote:

 

I guess I should say again that no one needs to depend directly on these - 
Clojure will include them via dependency. At some point there will may be a 
newer version of these libs you wish to use than the one included by Clojure 
and only in that case would you need to include it directly.

 

On Wed, Apr 26, 2017 at 7:54 PM, Alex Miller <a...@puredanger.com> wrote:

[org.clojure/spec.alpha "0.1.94"]

[org.clojure/core.specs.alpha "0.1.10"]

 

are available now.



On Wednesday, April 26, 2017 at 1:28:05 PM UTC-5, Sean Corfield wrote:

Whilst this is rather disruptive for current users of clojure.spec, I 
understand and appreciate the goal.

 

I hope that the new org.clojure/spec.alpha will be made available for a few 
days ahead of actually removing it from Clojure 1.9 so that those of us already 
using it and doing multi-version against master-SNAPSHOT will have a few days 
to update our code rather than just see our dev builds break and get blocked 
while we’re forced to make this code change?

 

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

 

-- 
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 a topic in the Google 
Groups "Clojure" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/clojure/10dbF7w2IQo/unsubscribe.
To unsubscribe from this group and all its topics, 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.


-- 
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] Clojure 1.9 / clojure.spec split

[Alex Miller]

I guess I should say again that no one needs to depend directly on these -
Clojure will include them via dependency. At some point there will may be a
newer version of these libs you wish to use than the one included by
Clojure and only in that case would you need to include it directly.

On Wed, Apr 26, 2017 at 7:54 PM, Alex Miller <a...@puredanger.com> wrote:

> [org.clojure/spec.alpha "0.1.94"]
> [org.clojure/core.specs.alpha "0.1.10"]
>
> are available now.
>
>
> On Wednesday, April 26, 2017 at 1:28:05 PM UTC-5, Sean Corfield wrote:
>>
>> Whilst this is rather disruptive for current users of clojure.spec, I
>> understand and appreciate the goal.
>>
>>
>>
>> I hope that the new org.clojure/spec.alpha will be made available for a
>> few days ahead of actually removing it from Clojure 1.9 so that those of us
>> already using it and doing multi-version against master-SNAPSHOT will have
>> a few days to update our code rather than just see our dev builds break and
>> get blocked while we’re forced to make this code change?
>>
>>
>>
>> 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
>>
>>
>> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/clojure/10dbF7w2IQo/unsubscribe.
> To unsubscribe from this group and all its topics, 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: [ANN] Clojure 1.9 / clojure.spec split

[Alex Miller]

[org.clojure/spec.alpha "0.1.94"]
[org.clojure/core.specs.alpha "0.1.10"]

are available now.


On Wednesday, April 26, 2017 at 1:28:05 PM UTC-5, Sean Corfield wrote:
>
> Whilst this is rather disruptive for current users of clojure.spec, I 
> understand and appreciate the goal.
>
>  
>
> I hope that the new org.clojure/spec.alpha will be made available for a 
> few days ahead of actually removing it from Clojure 1.9 so that those of us 
> already using it and doing multi-version against master-SNAPSHOT will have 
> a few days to update our code rather than just see our dev builds break and 
> get blocked while we’re forced to make this code change?
>
>  
>
> 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
>
>
>

-- 
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] Clojure 1.9 / clojure.spec split

[Alex Miller]

On Wednesday, April 26, 2017 at 6:27:08 PM UTC-5, Colin Fleming wrote:
>
> Doesn't this mean that Clojure and spec will be mutually dependent, i.e. a 
> dependency cycle?
>

Yes
 

> Is that likely to cause problems for any tooling?
>

No? :)  Feedback wanted, though if you find that to not be the case.

We haven't landed the patch back into Clojure yet but Clojure's inclusion 
of the spec.alpha dependency will exclude its Clojure dependency and I 
don't think this cycle causes any problems as far as I can tell. The 
initial spec.alpha build will be source-only. Once the namespaces are 
removed from Clojure, subsequent builds will be AOT'ed. Once you get to 
that point, you've essentially got the same pile of classes (split into 2 
jars) that we have now, so it's hard for me to see where that goes wrong.

-- 
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] Clojure 1.9 / clojure.spec split

[Colin Fleming]

Doesn't this mean that Clojure and spec will be mutually dependent, i.e. a
dependency cycle? Is that likely to cause problems for any tooling?

On 27 April 2017 at 06:27, Sean Corfield <s...@corfield.org> wrote:

> Whilst this is rather disruptive for current users of clojure.spec, I
> understand and appreciate the goal.
>
>
>
> I hope that the new org.clojure/spec.alpha will be made available for a
> few days ahead of actually removing it from Clojure 1.9 so that those of us
> already using it and doing multi-version against master-SNAPSHOT will have
> a few days to update our code rather than just see our dev builds break and
> get blocked while we’re forced to make this code change?
>
>
>
> 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
>
>
>
> On 4/26/17, 8:30 AM, "Alex Miller" <clojure@googlegroups.com on behalf of
> a...@puredanger.com> wrote:
>
>
>
> We are moving spec out of the Clojure repo/artifact and into a library to
> make it easier to evolve spec independently from Clojure. While we consider
> spec to be an essential part of Clojure 1.9, there are a number of design
> concerns to resolve before it can be finalized. This allows us to move
> towards a production Clojure release (1.9) that depends on an alpha version
> of spec. Users can also pick up newer versions of the spec alpha library as
> desired. Additionally, this is a first step towards increased support for
> leveraging dependencies within Clojure.
>
>
>
> We will be creating two new contrib libraries that will contain the
> following (renamed) namespaces:
>
>
>
> *org.clojure/spec.alpha*
> clojure.spec.alpha  (previously clojure.spec)
> clojure.spec.gen.alpha  (previously clojure.spec.gen)
> clojure.spec.test.alpha (previously clojure.spec.test)
>
>
>
> *org.clojure/core.specs.alpha*
> clojure.core.specs.alpha(previously clojure.core.specs)
>
>
>
> In most cases, we expect that users have aliased their reference to the
> spec namespaces and updating to the changed namespaces will only require a
> single change at the point of the require.
>
>
>
> *How will ClojureScript's spec implementation change?*
>
>
>
> ClojureScript will also change namespace names to match Clojure.
> Eventually, the ClojureScript implementation may move out of ClojureScript
> and into the spec.alpha library - this is still under discussion.
>
>
>
> *Why do the libraries and namespaces end in alpha?*
>
>
>
> The "alpha" indicates that the spec API and implementation is still
> subject to change.
>
>
>
> *What will happen when the spec api is no longer considered alpha?*
>
>
>
> At that point we expect to release a non-alpha version of the spec library
> (with non-alpha namespaces). Users may immediately begin to use that
> version of spec along with whatever version of Clojure it depends on.
> Clojure itself will depend on it at some later point. Timing of all these
> actions is TBD.
>
>
>
> *Will the library support Clojure 1.8 or older versions?*
>
>
>
> No. spec uses new functions in Clojure 1.9 and it has never been a goal to
> provide spec for older versions. Rather, we are trying to accelerate the
> release of a stable Clojure 1.9 so that users can migrate forward to a
> stable production release with access to an alpha version of spec, and
> access to ongoing updated versions as they become available.
>
>
>
> --
> 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+unsubsc

Re: [ANN] Clojure 1.9 / clojure.spec split

[Sean Corfield]

Whilst this is rather disruptive for current users of clojure.spec, I 
understand and appreciate the goal.

 

I hope that the new org.clojure/spec.alpha will be made available for a few 
days ahead of actually removing it from Clojure 1.9 so that those of us already 
using it and doing multi-version against master-SNAPSHOT will have a few days 
to update our code rather than just see our dev builds break and get blocked 
while we’re forced to make this code change?

 

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

 

On 4/26/17, 8:30 AM, "Alex Miller" <clojure@googlegroups.com on behalf of 
a...@puredanger.com> wrote:

 

We are moving spec out of the Clojure repo/artifact and into a library to make 
it easier to evolve spec independently from Clojure. While we consider spec to 
be an essential part of Clojure 1.9, there are a number of design concerns to 
resolve before it can be finalized. This allows us to move towards a production 
Clojure release (1.9) that depends on an alpha version of spec. Users can also 
pick up newer versions of the spec alpha library as desired. Additionally, this 
is a first step towards increased support for leveraging dependencies within 
Clojure.

 

We will be creating two new contrib libraries that will contain the following 
(renamed) namespaces:

 

org.clojure/spec.alpha
clojure.spec.alpha  (previously clojure.spec)
clojure.spec.gen.alpha  (previously clojure.spec.gen)
clojure.spec.test.alpha (previously clojure.spec.test)

 

org.clojure/core.specs.alpha
clojure.core.specs.alpha(previously clojure.core.specs)

 

In most cases, we expect that users have aliased their reference to the spec 
namespaces and updating to the changed namespaces will only require a single 
change at the point of the require.

 

How will ClojureScript's spec implementation change?

 

ClojureScript will also change namespace names to match Clojure. Eventually, 
the ClojureScript implementation may move out of ClojureScript and into the 
spec.alpha library - this is still under discussion.

 

Why do the libraries and namespaces end in alpha?

 

The "alpha" indicates that the spec API and implementation is still subject to 
change.

 

What will happen when the spec api is no longer considered alpha?

 

At that point we expect to release a non-alpha version of the spec library 
(with non-alpha namespaces). Users may immediately begin to use that version of 
spec along with whatever version of Clojure it depends on. Clojure itself will 
depend on it at some later point. Timing of all these actions is TBD.

 

Will the library support Clojure 1.8 or older versions?

 

No. spec uses new functions in Clojure 1.9 and it has never been a goal to 
provide spec for older versions. Rather, we are trying to accelerate the 
release of a stable Clojure 1.9 so that users can migrate forward to a stable 
production release with access to an alpha version of spec, and access to 
ongoing updated versions as they become available.

 

-- 
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: [ANN] Clojure 1.9 / clojure.spec split

[Alex Miller]

On Wednesday, April 26, 2017 at 11:32:39 AM UTC-5, Leon Grapenthin wrote:
>
> Thanks for the update, this seems like a good decision allowing things to 
> evolve more quickly.
>
> Does that also mean that there are no breaking changes intended to current 
> non .alpha namespaces/APIs? 
>

1.9 itself is still in alpha and so there may be breaking changes to 
anything new in 1.9 (new predicate functions, etc). Hopefully we will be 
able to proceed more rapidly towards a final release of 1.9 though.

-- 
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] Clojure 1.9 / clojure.spec split

[Leon Grapenthin]

Thanks for the update, this seems like a good decision allowing things to 
evolve more quickly.

Does that also mean that there are no breaking changes intended to current 
non .alpha namespaces/APIs? 

Kind regards,
 Leon

On Wednesday, April 26, 2017 at 5:30:56 PM UTC+2, Alex Miller wrote:
>
> We are moving spec out of the Clojure repo/artifact and into a library to 
> make it easier to evolve spec independently from Clojure. While we consider 
> spec to be an essential part of Clojure 1.9, there are a number of design 
> concerns to resolve before it can be finalized. This allows us to move 
> towards a production Clojure release (1.9) that depends on an alpha version 
> of spec. Users can also pick up newer versions of the spec alpha library as 
> desired. Additionally, this is a first step towards increased support for 
> leveraging dependencies within Clojure.
>
>
> We will be creating two new contrib libraries that will contain the 
> following (renamed) namespaces:
>
>
> *org.clojure/spec.alpha*
> clojure.spec.alpha  (previously clojure.spec)
> clojure.spec.gen.alpha  (previously clojure.spec.gen)
> clojure.spec.test.alpha (previously clojure.spec.test)
>
>
> *org.clojure/core.specs.alpha*
> clojure.core.specs.alpha(previously clojure.core.specs)
>
>
> In most cases, we expect that users have aliased their reference to the 
> spec namespaces and updating to the changed namespaces will only require a 
> single change at the point of the require.
>
>
> *How will ClojureScript's spec implementation change?*
>
>
> ClojureScript will also change namespace names to match Clojure. 
> Eventually, the ClojureScript implementation may move out of ClojureScript 
> and into the spec.alpha library - this is still under discussion.
>
>
> *Why do the libraries and namespaces end in alpha?*
>
>
> The "alpha" indicates that the spec API and implementation is still 
> subject to change.
>
>
> *What will happen when the spec api is no longer considered alpha?*
>
>
> At that point we expect to release a non-alpha version of the spec library 
> (with non-alpha namespaces). Users may immediately begin to use that 
> version of spec along with whatever version of Clojure it depends on. 
> Clojure itself will depend on it at some later point. Timing of all these 
> actions is TBD.
>
>
> *Will the library support Clojure 1.8 or older versions?*
>
>
> No. spec uses new functions in Clojure 1.9 and it has never been a goal to 
> provide spec for older versions. Rather, we are trying to accelerate the 
> release of a stable Clojure 1.9 so that users can migrate forward to a 
> stable production release with access to an alpha version of spec, and 
> access to ongoing updated versions as they become available.
>
>
>

-- 
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] Clojure 1.9 / clojure.spec split

[Tatu Tarvainen]

Thanks for the update.

This seems like a good decision that moves Clojure forward without tying 
your hands as to the future direction of 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.

[ANN] Clojure 1.9 / clojure.spec split

[Alex Miller]

We are moving spec out of the Clojure repo/artifact and into a library to 
make it easier to evolve spec independently from Clojure. While we consider 
spec to be an essential part of Clojure 1.9, there are a number of design 
concerns to resolve before it can be finalized. This allows us to move 
towards a production Clojure release (1.9) that depends on an alpha version 
of spec. Users can also pick up newer versions of the spec alpha library as 
desired. Additionally, this is a first step towards increased support for 
leveraging dependencies within Clojure.


We will be creating two new contrib libraries that will contain the 
following (renamed) namespaces:


*org.clojure/spec.alpha*
clojure.spec.alpha  (previously clojure.spec)
clojure.spec.gen.alpha  (previously clojure.spec.gen)
clojure.spec.test.alpha (previously clojure.spec.test)


*org.clojure/core.specs.alpha*
clojure.core.specs.alpha(previously clojure.core.specs)


In most cases, we expect that users have aliased their reference to the 
spec namespaces and updating to the changed namespaces will only require a 
single change at the point of the require.


*How will ClojureScript's spec implementation change?*


ClojureScript will also change namespace names to match Clojure. 
Eventually, the ClojureScript implementation may move out of ClojureScript 
and into the spec.alpha library - this is still under discussion.


*Why do the libraries and namespaces end in alpha?*


The "alpha" indicates that the spec API and implementation is still subject 
to change.


*What will happen when the spec api is no longer considered alpha?*


At that point we expect to release a non-alpha version of the spec library 
(with non-alpha namespaces). Users may immediately begin to use that 
version of spec along with whatever version of Clojure it depends on. 
Clojure itself will depend on it at some later point. Timing of all these 
actions is TBD.


*Will the library support Clojure 1.8 or older versions?*


No. spec uses new functions in Clojure 1.9 and it has never been a goal to 
provide spec for older versions. Rather, we are trying to accelerate the 
release of a stable Clojure 1.9 so that users can migrate forward to a 
stable production release with access to an alpha version of spec, and 
access to ongoing updated versions as they become available.


-- 
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: clojure.spec explain and multi-arity functions with first optional argument

[Leon Grapenthin]

Please try whether my CLJ-2013 
<https://dev.clojure.org/jira/browse/CLJ-2013> patch fixes the issue for 
you. From my observation it should.

On Saturday, April 22, 2017 at 7:31:48 PM UTC+2, Yegor Timoshenko wrote:
>
> (require '[clojure.spec :as s])
> (require '[clojure.spec.test :refer [instrument]])
>
> (defn request ([url]) ([params url]))
>
> (s/fdef request
>   :args (s/cat :params (s/? map?) :url string?))
>
> (instrument `request)
> (request [] "")
>
> ExceptionInfo Call to #'user/request did not conform to spec:
> In: [0] val: [] fails at: [:args :url] predicate: string?
> :clojure.spec/args  ([] "")
> :clojure.spec/failure  :instrument
> :clojure.spec.test/caller  {:file "form-init1226863901212006294.clj", 
> :line 1, :var-scope user/eval2193}
>   clojure.core/ex-info (core.clj:4725)
>
> I expected that it would fail at `map?` predicate rather than at `string?` 
> predicate.
> s/or produces better explanation, but at the same time is relatively more 
> verbose:
>
> (require '[clojure.spec :as s])
> (require '[clojure.spec.test :refer [instrument]])
>
> (defn request ([url]) ([params url]))
>
> (s/fdef request
>   :args (s/or :simple (s/cat :url string?)
>:advanced (s/cat :params map? :url string?)))
>
> (instrument `request)
> (request [] "")
>
> ExceptionInfo Call to #'user/request did not conform to spec:
> In: [0] val: [] fails at: [:args :simple :url] predicate: string?
> In: [0] val: [] fails at: [:args :advanced :params] predicate: map?
> :clojure.spec/args  ([] "")
> :clojure.spec/failure  :instrument
> :clojure.spec.test/caller  {:file "form-init1226863901212006294.clj", 
> :line 1, :var-scope user/eval2208}
>   clojure.core/ex-info (core.clj:4725)
>
> Is it subject to improvement? https://dev.clojure.org/jira/browse/CLJ-1982 
> might be the same issue.
>

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

clojure.spec explain and multi-arity functions with first optional argument

[Yegor Timoshenko]

(require '[clojure.spec :as s])
(require '[clojure.spec.test :refer [instrument]])

(defn request ([url]) ([params url]))

(s/fdef request
  :args (s/cat :params (s/? map?) :url string?))

(instrument `request)
(request [] "")

ExceptionInfo Call to #'user/request did not conform to spec:
In: [0] val: [] fails at: [:args :url] predicate: string?
:clojure.spec/args  ([] "")
:clojure.spec/failure  :instrument
:clojure.spec.test/caller  {:file "form-init1226863901212006294.clj", :line 
1, :var-scope user/eval2193}
  clojure.core/ex-info (core.clj:4725)

I expected that it would fail at `map?` predicate rather than at `string?` 
predicate.
s/or produces better explanation, but at the same time is relatively more 
verbose:

(require '[clojure.spec :as s])
(require '[clojure.spec.test :refer [instrument]])

(defn request ([url]) ([params url]))

(s/fdef request
  :args (s/or :simple (s/cat :url string?)
   :advanced (s/cat :params map? :url string?)))

(instrument `request)
(request [] "")

ExceptionInfo Call to #'user/request did not conform to spec:
In: [0] val: [] fails at: [:args :simple :url] predicate: string?
In: [0] val: [] fails at: [:args :advanced :params] predicate: map?
:clojure.spec/args  ([] "")
:clojure.spec/failure  :instrument
:clojure.spec.test/caller  {:file "form-init1226863901212006294.clj", :line 
1, :var-scope user/eval2208}
  clojure.core/ex-info (core.clj:4725)

Is it subject to improvement? https://dev.clojure.org/jira/browse/CLJ-1982 
might be the same issue.

-- 
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: Seeking critique of "pattern" in clojure.spec (LONG)

[Brian Beckman]

I should have called them "blueberries" instead of the more provocative 
"virtual times."  I was trying to go from an abstract mathematical 
definition to a formalization in Clojure. Eventually, virtual times will be 
part of a discrete-even simulation platform, but it's too early to say much 
about that now. I'm just setting up the pylons at present.

Clojure number? excluding NaN will do for now: they have the required 
semantics at the limits and they're comparable amongst Double, Integer, 
Fraction, etc. Later, I may need a density axiom ("between any two finite 
blueberries there is another blueberry") and that's not true for Doubles. 
At that point I will definitely look back at your excellent answer and 
consider s/fdef's.

On Monday, April 10, 2017 at 10:15:19 PM UTC-7, Didier wrote:
>
> Here it is adapted to use a deftype: 
> https://gist.github.com/didibus/2ccd608ed9d226039f944b02a10f9ad5
>
> I gather from your solution that "orchestra" is not needed to spec :ret 
>> types?
>>
>
> It is not. The return spec will be used during st/check. If you want the 
> return spec to be validated outside of st/check though, than you need 
> Orchestra.
>
> I shall have to read up on deftype versus defrecord.
>>
>
> I recommend the clojure.org explanation: 
> https://clojure.org/reference/datatypes#_deftype_and_defrecord
> In a nutshell, deftype is a blank Java class, defrecord is an extended 
> PersistentHashMap.
>
> I am not sure why you need a VirtualTime, and what it will be doing, so I 
> can't really comment on which solution is best. As James said, it appears 
> you might be creating something that behaves the same way Double does? 
> Double already has positive and negative infinity and NaN:
>
> (/ 0.0 0.0) ; NaN
> (* 99e 99e) ; Infinity
> (* 99e -99e) ; -Infinity
> (< Double/NEGATIVE_INFINITY Double/POSITIVE_INFINITY) ; true
> (= Double/NEGATIVE_INFINITY Double/POSITIVE_INFINITY) ; false
>
> I'd suggest, if you need Double, use Double. If you need something close 
> to Double, and you can build on top of it, simpler to go with the style of 
> my first gist. If you can't build on top of double, deftype is probably 
> what you want.
>
> On Monday, 10 April 2017 21:41:35 UTC-7, Brian Beckman wrote:
>>
>> Wow... that's a comprehensive solution, Didier :) Bravo! It's a good 
>> lesson for s/fdef, which I haven't yet studied. I gather from your solution 
>> that "orchestra" is not needed to spec :ret types?
>>
>> As to semantics, on the one hand, I can spec ::virtual-time as a light 
>> overlay over Double and risk conflation of ordinary operators like < <= = 
>> etc. On the other hand, I have several options for full protection. I shall 
>> have to read up on deftype versus defrecord.
>>
>

-- 
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: Seeking critique of "pattern" in clojure.spec (LONG)

[Didier]

Here it is adapted to use a 
deftype: https://gist.github.com/didibus/2ccd608ed9d226039f944b02a10f9ad5

I gather from your solution that "orchestra" is not needed to spec :ret 
> types?
>

It is not. The return spec will be used during st/check. If you want the 
return spec to be validated outside of st/check though, than you need 
Orchestra.

I shall have to read up on deftype versus defrecord.
>

I recommend the clojure.org explanation: 
https://clojure.org/reference/datatypes#_deftype_and_defrecord
In a nutshell, deftype is a blank Java class, defrecord is an extended 
PersistentHashMap.

I am not sure why you need a VirtualTime, and what it will be doing, so I 
can't really comment on which solution is best. As James said, it appears 
you might be creating something that behaves the same way Double does? 
Double already has positive and negative infinity and NaN:

(/ 0.0 0.0) ; NaN
(* 99e 99e) ; Infinity
(* 99e -99e) ; -Infinity
(< Double/NEGATIVE_INFINITY Double/POSITIVE_INFINITY) ; true
(= Double/NEGATIVE_INFINITY Double/POSITIVE_INFINITY) ; false

I'd suggest, if you need Double, use Double. If you need something close to 
Double, and you can build on top of it, simpler to go with the style of my 
first gist. If you can't build on top of double, deftype is probably what 
you want.

On Monday, 10 April 2017 21:41:35 UTC-7, Brian Beckman wrote:
>
> Wow... that's a comprehensive solution, Didier :) Bravo! It's a good 
> lesson for s/fdef, which I haven't yet studied. I gather from your solution 
> that "orchestra" is not needed to spec :ret types?
>
> As to semantics, on the one hand, I can spec ::virtual-time as a light 
> overlay over Double and risk conflation of ordinary operators like < <= = 
> etc. On the other hand, I have several options for full protection. I shall 
> have to read up on deftype versus defrecord.
>

-- 
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: Seeking critique of "pattern" in clojure.spec (LONG)

[Brian Beckman]

Wow... that's a comprehensive solution, Didier :) Bravo! It's a good lesson for 
s/fdef, which I haven't yet studied. I gather from your solution that 
"orchestra" is not needed to spec :ret types?

As to semantics, on the one hand, I can spec ::virtual-time as a light overlay 
over Double and risk conflation of ordinary operators like < <= = etc. On the 
other hand, I have several options for full protection. I shall have to read up 
on deftype versus defrecord.

-- 
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: Seeking critique of "pattern" in clojure.spec (LONG)

[James Reeves]

Using the preset infinity constants is probably the best solution in this
case. :)

- James

On 11 April 2017 at 01:50, Brian Beckman  wrote:

> James -- just the kind of simplification I was looking for! In fact, I
> think the following will do everything I need --- generate numbers avoiding
> only NaN (which isn't equal to itself, nor less than anything)
>
> (s/def ::virtual-time
>   (s/with-gen
> (s/and
>  number? #(not (Double/isNaN %)))
> ;; We'd like most values generated in tests to be finite, with the
> ;; occasional infinity for spice. Adjust these frequencies to taste.
> #(gen/frequency [[98 (s/gen number?)]
>  [ 1 (gen/return Double/NEGATIVE_INFINITY)]
>  [ 1 (gen/return Double/POSITIVE_INFINITY)]])))
>
>
>
> --
> 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: Seeking critique of "pattern" in clojure.spec (LONG)

[Didier]

I agree with James, here's what I'd 
do: https://gist.github.com/didibus/d0228ffad9b920c201410806b157ff10

The only downside, and why you might still want to use types (probably with 
deftype), is to prevent people from using standard functions like <,>,= 
etc. If you deftyped virtual-time, it could not accidentally be used like a 
normal number. Ideally, you'd extend the Java Comparable interface too.

On Monday, 10 April 2017 17:50:58 UTC-7, Brian Beckman wrote:
>
> James -- just the kind of simplification I was looking for! In fact, I 
> think the following will do everything I need --- generate numbers avoiding 
> only NaN (which isn't equal to itself, nor less than anything)
>
> (s/def ::virtual-time
>   (s/with-gen
> (s/and
>  number? #(not (Double/isNaN %)))
> ;; We'd like most values generated in tests to be finite, with the
> ;; occasional infinity for spice. Adjust these frequencies to taste.
> #(gen/frequency [[98 (s/gen number?)]
>  [ 1 (gen/return Double/NEGATIVE_INFINITY)]
>  [ 1 (gen/return Double/POSITIVE_INFINITY)]])))
>
>
>
>

-- 
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: Seeking critique of "pattern" in clojure.spec (LONG)

[Brian Beckman]

James -- just the kind of simplification I was looking for! In fact, I 
think the following will do everything I need --- generate numbers avoiding 
only NaN (which isn't equal to itself, nor less than anything)

(s/def ::virtual-time
  (s/with-gen
(s/and
 number? #(not (Double/isNaN %)))
;; We'd like most values generated in tests to be finite, with the
;; occasional infinity for spice. Adjust these frequencies to taste.
#(gen/frequency [[98 (s/gen number?)]
 [ 1 (gen/return Double/NEGATIVE_INFINITY)]
 [ 1 (gen/return Double/POSITIVE_INFINITY)]])))



-- 
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: Seeking critique of "pattern" in clojure.spec (LONG)

[James Reeves]

I think what you have is overly complex for what you want to do.

Consider this alternative spec:

  (s/def ::virtual-time
(s/or :number number?, :limit #{::infinity- ::infinity+}))

Then we write a comparator:

  (defn compare-times [a b]
(cond
  (= a b) 0
  (= a ::infinity+) +1
  (= a ::infinity-) -1
  (= b ::infinity+) -1
  (= b ::infinity-) +1
  :else (compare a b)))

>From there we can derive less-than and greater-than functions if we really
need them.

I don't think you need protocols, records or custom generators.

- James

On 10 April 2017 at 17:30, Brian Beckman  wrote:

> "I apologize for the length of this post ..."  Blaise Pascal?
>
> I am seeking critique of a certain "programming pattern" that's arisen
> several times in a project. I want testable types satisfying a protocol,
> but the pattern I developed "feels" heavyweight, as the example will show,
> but I don't know a smaller way to get what I want. The amount of code I
> needed to formalize and test my specs "feels" like too much. In particular,
> the introduction of a defrecord just to support the protocol doesn't "feel"
> minimal. The defrecord provides a constructor with positional args — of
> dubious utility — especially for large records, but otherwise acts like a
> hashmap. Perhaps there is a way to bypass the defrecord and directly use a
> hashmap?
>
> Generally, I am suspicious of "programming patterns," because I believe
> that an apparent need for a programming pattern usually means one of two
> things:
>
>1.
>
>The programming language doesn't directly support some reasonable
>need, and that's not usually the case with Clojure
>2.
>
>Ignorance: I don't know an idiomatic way to do what I want.
>
> There is a remote, third possibility, that "what I want" is stupid,
> ignorant, or otherwise unreasonable.
> Here is what I settled on: quadruples of protocol, defrecord, specs and
> tests to fully describe and test types in my application:
>
>1.
>
>a protocol to declare functions that certain types must implement
>2.
>
>at least one defrecord to implement the protocol
>3.
>
>a spec to package checks and test generators
>4.
>
>tests to, well, test them
>
> For a small example (my application has some that are much bigger),
> consider a type that models "virtual times" as numbers-with-infinities.
> Informally, a "virtual time" is either a number or one of two distinguished
> values for plus and minus infinity. Minus infinity is less than any virtual
> time other than minus infinity. Plus infinity is greater than any virtual
> time other than plus infinity." I'll write a protocol, a defrecord, a spec,
> and a couple of tests for this type.
>
> In the actual code, the elements come in the order of protocol, defrecord,
> spec, and tests because of cascading dependencies. For human consumption,
> I'll "detangle" them and present the spec first:
>
> (s/def ::virtual-time  (s/with-gen(s/and ; idiom for providing a 
> "conformer" function below (s/or  :minus-infinity #(vt-eq % 
> :vt-negative-infinity) ; see the protocol for "vt-eq"  :plus-infinity  
> #(vt-eq % :vt-positive-infinity)  :number #(number? (:vt %))) 
> (s/conformer second))  ; strip off redundant conformer tag
> #(gen/frequency [[98 vt-number-gen] ; generate mostly numbers ... 
> [ 1 vt-negative-infinity-gen] ; ... with occasional infinities
>  [ 1 vt-positive-infinity-gen]])))
>
> That should be self-explanatory given the following definitions:
>
> (def vt-number-gen  (gen/bind   (gen/large-integer)   (fn [vt] (gen/return 
> (virtual-time. vt) ; invoke constructor ... heavyweight?​(def 
> vt-negative-infinity-gen  (gen/return (virtual-time. 
> :vt-negative-infinity)))​(def vt-positive-infinity-gen  (gen/return 
> (virtual-time. :vt-positive-infinity)))
>
> The tests use the generators and a couple of global variables:
>
> (def vt-negative-infinity (virtual-time. :vt-negative-infinity))(def 
> vt-positive-infinity (virtual-time. :vt-positive-infinity))​(defspec 
> minus-infinity-less-than-all-but-minus-infinity  100  (prop/for-all   [vt 
> (s/gen :pattern-mve.core/virtual-time)]   (if (not= (:vt vt) 
> :vt-negative-infinity) (vt-lt vt-negative-infinity vt) ; see the protocol 
> for def of "vt-lt" true)))​(defspec plus-infinity-not-less-than-any  100  
> (prop/for-all   [vt (s/gen :pattern-mve.core/virtual-time)]   (not (vt-lt 
> vt-positive-infinity vt
>
> The protocol specifies the comparison operators "vt-lt" and "vt-le." A
> defrecord to implement it should now be obvious, given understanding of how
> they're used above:
>
> (defprotocol VirtualTimeT  (vt-lt [this-vt that-vt])  (vt-le [this-vt 
> that-vt])  (vt-eq [this-vt that-vt]))​(defn -vt-compare-lt [this-vt that-vt]  
> (case (:vt this-vt):vt-negative-infinity(case (:vt that-vt)  
> 

Re: Seeking critique of "pattern" in clojure.spec (LONG)

[Brian Beckman]

These are good comments that give me things to think about. I'm grateful.
* The pattern concerned me because (1) it was just the first thing I came 
up with, so not sure there wasn't a better way staring me in the face (2) I 
didn't see any clearly better alternatives, so not sure whether I just 
don't know enough Clojure (3) it intuitively felt heavyweight with at least 
four "complected" language features.
* Understood about polymorphism. In my real app, I have a lot of it, but I 
thought I would use protocols & records even when I don't have polymorphism 
just for uniformity of style: one way to express my "testable types." 
* You've pointed out an overlap between two different ways to specify 
structure: (A) requiring keys via records and (B) requiring keys using 
specs over ordinary maps. Starting with records, I sensed that some of my 
specs were actually vapid, and now you've told me why.  
* I think experimenting with mere (collections of) functions over mere maps 
with structure enforced by specs is a good idea. I'll try it and "weigh" it 
against this alternative.


On Monday, April 10, 2017 at 1:13:49 PM UTC-7, Didier wrote:
>
> I think this pattern is fine.
>
> What specifically about it annoys you?
>
> You could do it without records, but then you wouldn't be creating a type. 
> Do you really need a type?
>
> The advantage of types in Clojure are that they let you do polymorphic 
> dispatch of them. So they are useful if you have one function which you 
> want to reuse for many types.
>
> In your case, I'm not seeing other records implementing the protocol. So 
> it doesn't seem you need polymorphic dispatch on type. So maybe you can 
> drop the protocol.
>
> Records are useful if you need a map with guaranteed keys. Spec makes this 
> feature less useful, because you can now spec a map and test that it always 
> has the right keys when used. If you have a record, a fn that works over 
> that record just needs to check the argument has the type of record, and it 
> knows the keys exist. If you have a map instead, the fn would need to check 
> the keys exist.
>
> Records don't support unions, all keys must exist. In your case, you want 
> unions, a map with keys x,y or z. So if you use a record, some keys will 
> always have nil value. So, again, you might be better served by a map.
>
> Recap. Protocols if you want a common interface accross multiple types. 
> Records if you want to create a map with guaranteed keys, which will 
> identify itself as a named java type.
>
> Your spec can't really be made shorter, since they need custom gens.
>
> If I was you, I'd experiment with functions over maps. One thing to 
> consider is that specs are structural types, not nominal. So if you spec a 
> map, it describes its structure. A function says I take a structure of that 
> shape, if you give me anything that conforms, I can successfully do my job. 
> The shape itself has no known runtime name.
>
>

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

Seeking critique of "pattern" in clojure.spec (LONG)

[Didier]

I think this pattern is fine.

What specifically about it annoys you?

You could do it without records, but then you wouldn't be creating a type. Do 
you really need a type?

The advantage of types in Clojure are that they let you do polymorphic dispatch 
of them. So they are useful if you have one function which you want to reuse 
for many types.

In your case, I'm not seeing other records implementing the protocol. So it 
doesn't seem you need polymorphic dispatch on type. So maybe you can drop the 
protocol.

Records are useful if you need a map with guaranteed keys. Spec makes this 
feature less useful, because you can now spec a map and test that it always has 
the right keys when used. If you have a record, a fn that works over that 
record just needs to check the argument has the type of record, and it knows 
the keys exist. If you have a map instead, the fn would need to check the keys 
exist.

Records don't support unions, all keys must exist. In your case, you want 
unions, a map with keys x,y or z. So if you use a record, some keys will always 
have nil value. So, again, you might be better served by a map.

Recap. Protocols if you want a common interface accross multiple types. Records 
if you want to create a map with guaranteed keys, which will identify itself as 
a named java type.

Your spec can't really be made shorter, since they need custom gens.

If I was you, I'd experiment with functions over maps. One thing to consider is 
that specs are structural types, not nominal. So if you spec a map, it 
describes its structure. A function says I take a structure of that shape, if 
you give me anything that conforms, I can successfully do my job. The shape 
itself has no known runtime name.

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

Seeking critique of "pattern" in clojure.spec (LONG)

[Brian Beckman]

"I apologize for the length of this post ..."  Blaise Pascal?

I am seeking critique of a certain "programming pattern" that's arisen 
several times in a project. I want testable types satisfying a protocol, 
but the pattern I developed "feels" heavyweight, as the example will show, 
but I don't know a smaller way to get what I want. The amount of code I 
needed to formalize and test my specs "feels" like too much. In particular, 
the introduction of a defrecord just to support the protocol doesn't "feel" 
minimal. The defrecord provides a constructor with positional args — of 
dubious utility — especially for large records, but otherwise acts like a 
hashmap. Perhaps there is a way to bypass the defrecord and directly use a 
hashmap?

Generally, I am suspicious of "programming patterns," because I believe 
that an apparent need for a programming pattern usually means one of two 
things:

   1. 
   
   The programming language doesn't directly support some reasonable need, 
   and that's not usually the case with Clojure
   2. 
   
   Ignorance: I don't know an idiomatic way to do what I want.
   
There is a remote, third possibility, that "what I want" is stupid, 
ignorant, or otherwise unreasonable. 
Here is what I settled on: quadruples of protocol, defrecord, specs and 
tests to fully describe and test types in my application:

   1. 
   
   a protocol to declare functions that certain types must implement
   2. 
   
   at least one defrecord to implement the protocol
   3. 
   
   a spec to package checks and test generators
   4. 
   
   tests to, well, test them
   
For a small example (my application has some that are much bigger), 
consider a type that models "virtual times" as numbers-with-infinities. 
Informally, a "virtual time" is either a number or one of two distinguished 
values for plus and minus infinity. Minus infinity is less than any virtual 
time other than minus infinity. Plus infinity is greater than any virtual 
time other than plus infinity." I'll write a protocol, a defrecord, a spec, 
and a couple of tests for this type. 

In the actual code, the elements come in the order of protocol, defrecord, 
spec, and tests because of cascading dependencies. For human consumption, 
I'll "detangle" them and present the spec first:

(s/def ::virtual-time  (s/with-gen(s/and ; idiom for providing a 
"conformer" function below (s/or  :minus-infinity #(vt-eq % 
:vt-negative-infinity) ; see the protocol for "vt-eq"  :plus-infinity  
#(vt-eq % :vt-positive-infinity)  :number #(number? (:vt %))) 
(s/conformer second))  ; strip off redundant conformer tag
#(gen/frequency [[98 vt-number-gen] ; generate mostly numbers ...   
  [ 1 vt-negative-infinity-gen] ; ... with occasional infinities
 [ 1 vt-positive-infinity-gen]])))

That should be self-explanatory given the following definitions:

(def vt-number-gen  (gen/bind   (gen/large-integer)   (fn [vt] (gen/return 
(virtual-time. vt) ; invoke constructor ... heavyweight?​(def 
vt-negative-infinity-gen  (gen/return (virtual-time. 
:vt-negative-infinity)))​(def vt-positive-infinity-gen  (gen/return 
(virtual-time. :vt-positive-infinity)))

The tests use the generators and a couple of global variables:

(def vt-negative-infinity (virtual-time. :vt-negative-infinity))(def 
vt-positive-infinity (virtual-time. :vt-positive-infinity))​(defspec 
minus-infinity-less-than-all-but-minus-infinity  100  (prop/for-all   [vt 
(s/gen :pattern-mve.core/virtual-time)]   (if (not= (:vt vt) 
:vt-negative-infinity) (vt-lt vt-negative-infinity vt) ; see the protocol 
for def of "vt-lt" true)))​(defspec plus-infinity-not-less-than-any  100  
(prop/for-all   [vt (s/gen :pattern-mve.core/virtual-time)]   (not (vt-lt 
vt-positive-infinity vt

The protocol specifies the comparison operators "vt-lt" and "vt-le." A 
defrecord to implement it should now be obvious, given understanding of how 
they're used above:

(defprotocol VirtualTimeT  (vt-lt [this-vt that-vt])  (vt-le [this-vt that-vt]) 
 (vt-eq [this-vt that-vt]))​(defn -vt-compare-lt [this-vt that-vt]  (case (:vt 
this-vt):vt-negative-infinity(case (:vt that-vt)  
:vt-negative-infinity false  #_otherwise true)​:vt-positive-infinity
false​;; otherwise: this-vt is a number.(case (:vt that-vt)  
:vt-positive-infinity true  :vt-negative-infinity false  #_otherwise (< 
(:vt this-vt) (:vt that-vt)​(defrecord virtual-time [vt]  VirtualTimeT  
(vt-lt [this that] (-vt-compare-lt this that))  (vt-eq [this that] (= this 
that))  (vt-le [this that] (or (vt-eq this that) (vt-lt this that

Please see a runnable project here 
https://github.com/rebcabin/ClojureProjects/tree/working/pattern-mve 

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

Re: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Didier]

After a bit of digging, it appears that dependent types, at least the Liquid 
Haskell kind, could catch it, but could also miss it. If you've constrained 
everything very tightly, it would catch it, if not, it could miss it.

In this regard, generative testing could still end up being practically more 
useful.

Another thing is that dependent types (the Liquid Haskell kind), would also 
catch potential false positive.

I'll mention Spectrum for clojure.spec again, because it is essentially a 
dependently typed static type checker for Clojure. It suffers from not 
everything being specced in Clojure, but you'll find it can still catch quite a 
lot, including the division by zero error I've described. It is still in early 
stages, and doesn't work with all Clojure code bases, but I'd keep an eye open 
for it.

Reference: 
http://goto.ucsd.edu/~ucsdpl-blog/liquidtypes/2015/09/19/liquid-types/

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Didier]

Sorry, I didn't mean fraction type, I meant fraction literal. 

All I can say is neither Java, Kotlin or Ceylon have a non zero type. Not sure 
about heck or frege.

Also, I was eventually leading to more than just the literal 10/0. If the zero 
in this division comes from another formula, or is dynamically calculated, you 
won't catch this statically even if you have a non zero type.

I don't know enough about dependent types, I think they could catch this, 
maybe, I'm unsure. I do know that none of the asked languages have them. I've 
also heard from more knowledgeable people that they're still very verbose and 
unpractical. 

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Gregg Reynolds]

On Apr 8, 2017 3:47 PM, "Gregg Reynolds"  wrote:



On Apr 7, 2017 9:57 PM, "Didier"  wrote:

 | I think you missed my point, which is only "Spec is great as we have the
power of Clojure" - sure, just don't forget you have the power of ANOther
language in that language as well.

Hum, I've probably missed your point sorry, I'm still not following.

 | no, this will, or at least should, be caught. 10/0 is not an int, and
typed "/' would reject 0 as an ill-typed denominator.

In most static type systems this will not be caught, because they don't
have a fraction type.


"most" -ok.  that's empirical, eww!

So this is actually a function that takes two number types, and 0 is a
number too, so it will type check, but throw an exception at runtime.


maybe my mind has been twisted by dependent types. imho a definition of
"div" that accepts 0 as denominator is a bad defn, or at least a non-typed
defn.  "10/0" is ill-typed. this is obvious mathematically, right? division
by zero is undefined.  it's not really a question of "fraction types"; just
rewrite as (div 10 0).  you do not need a fraction type to define "/". what
you need is a type that does not include zero.


i would add that if you want real static typing you're almost forced to
support dependent types. unless you want a defn of static typing that
includes a great big "well, except for..  " clause.  like a fn that is only
defined for 0..9.


g

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Gregg Reynolds]

On Apr 7, 2017 9:57 PM, "Didier"  wrote:

 | I think you missed my point, which is only "Spec is great as we have the
power of Clojure" - sure, just don't forget you have the power of ANOther
language in that language as well.

Hum, I've probably missed your point sorry, I'm still not following.

 | no, this will, or at least should, be caught. 10/0 is not an int, and
typed "/' would reject 0 as an ill-typed denominator.

In most static type systems this will not be caught, because they don't
have a fraction type.


"most" -ok.  that's empirical, eww!

So this is actually a function that takes two number types, and 0 is a
number too, so it will type check, but throw an exception at runtime.


maybe my mind has been twisted by dependent types. imho a definition of
"div" that accepts 0 as denominator is a bad defn, or at least a non-typed
defn.  "10/0" is ill-typed. this is obvious mathematically, right? division
by zero is undefined.  it's not really a question of "fraction types"; just
rewrite as (div 10 0).  you do not need a fraction type to define "/". what
you need is a type that does not include zero.

g

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Colin Yates]

They look great. My main reservation about Kotlin (and Fantom?) is the
mutability. I fear Clojure has spoiled mutable data structures for me :-).

On Saturday, 8 April 2017, Didier  wrote:

> I have longed for a statically compiled language with type inference with
>>> the simplicity and consistency of Clojure's syntax that also supports
>>> generative testing and works on the JVM but alas, I have not found one.
>>> Frege and PureScript both look interesting but I am unsure of Frege's
>>> longevity and PureScript's performance on the JVM's Javascript
>>> environment.
>>
>>
>> Note that both of those options both suffer from very difficult interop -
>> PureScript will probably not have any at all since it will be expecting to
>> interop with JS, and Frege has some but it's clunky due to the type system
>> mismatch.
>>
>> Personally I long for a Kotlin/Clojure hybrid, to the point that I have
>> seriously considered trying to build one.
>>
>
> ShenLanguage  is maybe the closest thing from a
> fully typed Clojure on the JVM, though it also suffers from poor interop.
>
> I'd like to suggest Fantom . I wish more people used
> it. It is a functional/oop, actor concurrent, inference typed, static with
> optional dynamic typing language with good interop that runs on top of the
> JVM, CLR and JavaScript. It has a lot of similarities with Clojure, like a
> strong support for data literals such as for maps and lists, looping is
> mostly done through higher order functions, it has a subset of its own
> language as a data declaration format, immutable by default, strong
> concurrency support using actors model, etc. It just needs some love. I
> find at its core, its got a better offering than Kotlin.
>
> On Friday, 7 April 2017 20:34:34 UTC-7, Colin Fleming wrote:
>>
>> I have longed for a statically compiled language with type inference with
>>> the simplicity and consistency of Clojure's syntax that also supports
>>> generative testing and works on the JVM but alas, I have not found one.
>>> Frege and PureScript both look interesting but I am unsure of Frege's
>>> longevity and PureScript's performance on the JVM's Javascript
>>> environment.
>>
>>
>> Note that both of those options both suffer from very difficult interop -
>> PureScript will probably not have any at all since it will be expecting to
>> interop with JS, and Frege has some but it's clunky due to the type system
>> mismatch.
>>
>> Personally I long for a Kotlin/Clojure hybrid, to the point that I have
>> seriously considered trying to build one.
>>
>> On 8 April 2017 at 14:57, Didier  wrote:
>>
>>>  | I think you missed my point, which is only "Spec is great as we have
>>> the power of Clojure" - sure, just don't forget you have the power of
>>> ANOther language in that language as well.
>>>
>>> Hum, I've probably missed your point sorry, I'm still not following.
>>>
>>>  | no, this will, or at least should, be caught. 10/0 is not an int, and
>>> typed "/' would reject 0 as an ill-typed denominator.
>>>
>>> In most static type systems this will not be caught, because they don't
>>> have a fraction type. So this is actually a function that takes two number
>>> types, and 0 is a number too, so it will type check, but throw an exception
>>> at runtime.
>>>
>>> --
>>> 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.
>>>
>>
>> --
> 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 

Re: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Didier]

>
> I have longed for a statically compiled language with type inference with 
>> the simplicity and consistency of Clojure's syntax that also supports 
>> generative testing and works on the JVM but alas, I have not found one. 
>> Frege and PureScript both look interesting but I am unsure of Frege's 
>> longevity and PureScript's performance on the JVM's Javascript 
>> environment.
>
>
> Note that both of those options both suffer from very difficult interop - 
> PureScript will probably not have any at all since it will be expecting to 
> interop with JS, and Frege has some but it's clunky due to the type system 
> mismatch.
>
> Personally I long for a Kotlin/Clojure hybrid, to the point that I have 
> seriously considered trying to build one.
>

ShenLanguage  is maybe the closest thing from a 
fully typed Clojure on the JVM, though it also suffers from poor interop.

I'd like to suggest Fantom . I wish more people used 
it. It is a functional/oop, actor concurrent, inference typed, static with 
optional dynamic typing language with good interop that runs on top of the 
JVM, CLR and JavaScript. It has a lot of similarities with Clojure, like a 
strong support for data literals such as for maps and lists, looping is 
mostly done through higher order functions, it has a subset of its own 
language as a data declaration format, immutable by default, strong 
concurrency support using actors model, etc. It just needs some love. I 
find at its core, its got a better offering than Kotlin.

On Friday, 7 April 2017 20:34:34 UTC-7, Colin Fleming wrote:
>
> I have longed for a statically compiled language with type inference with 
>> the simplicity and consistency of Clojure's syntax that also supports 
>> generative testing and works on the JVM but alas, I have not found one. 
>> Frege and PureScript both look interesting but I am unsure of Frege's 
>> longevity and PureScript's performance on the JVM's Javascript 
>> environment.
>
>
> Note that both of those options both suffer from very difficult interop - 
> PureScript will probably not have any at all since it will be expecting to 
> interop with JS, and Frege has some but it's clunky due to the type system 
> mismatch.
>
> Personally I long for a Kotlin/Clojure hybrid, to the point that I have 
> seriously considered trying to build one.
>
> On 8 April 2017 at 14:57, Didier  wrote:
>
>>  | I think you missed my point, which is only "Spec is great as we have 
>> the power of Clojure" - sure, just don't forget you have the power of 
>> ANOther language in that language as well.
>>
>> Hum, I've probably missed your point sorry, I'm still not following.
>>
>>  | no, this will, or at least should, be caught. 10/0 is not an int, and 
>> typed "/' would reject 0 as an ill-typed denominator.
>>
>> In most static type systems this will not be caught, because they don't 
>> have a fraction type. So this is actually a function that takes two number 
>> types, and 0 is a number too, so it will type check, but throw an exception 
>> at runtime.
>>
>> --
>> 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.
>>
>
>

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Colin Fleming]

>
> I have longed for a statically compiled language with type inference with
> the simplicity and consistency of Clojure's syntax that also supports
> generative testing and works on the JVM but alas, I have not found one.
> Frege and PureScript both look interesting but I am unsure of Frege's
> longevity and PureScript's performance on the JVM's Javascript
> environment.


Note that both of those options both suffer from very difficult interop -
PureScript will probably not have any at all since it will be expecting to
interop with JS, and Frege has some but it's clunky due to the type system
mismatch.

Personally I long for a Kotlin/Clojure hybrid, to the point that I have
seriously considered trying to build one.

On 8 April 2017 at 14:57, Didier  wrote:

>  | I think you missed my point, which is only "Spec is great as we have
> the power of Clojure" - sure, just don't forget you have the power of
> ANOther language in that language as well.
>
> Hum, I've probably missed your point sorry, I'm still not following.
>
>  | no, this will, or at least should, be caught. 10/0 is not an int, and
> typed "/' would reject 0 as an ill-typed denominator.
>
> In most static type systems this will not be caught, because they don't
> have a fraction type. So this is actually a function that takes two number
> types, and 0 is a number too, so it will type check, but throw an exception
> at runtime.
>
> --
> 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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Didier]

 | I think you missed my point, which is only "Spec is great as we have the 
power of Clojure" - sure, just don't forget you have the power of ANOther 
language in that language as well.

Hum, I've probably missed your point sorry, I'm still not following.

 | no, this will, or at least should, be caught. 10/0 is not an int, and typed 
"/' would reject 0 as an ill-typed denominator.

In most static type systems this will not be caught, because they don't have a 
fraction type. So this is actually a function that takes two number types, and 
0 is a number too, so it will type check, but throw an exception at runtime. 

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Gregg Reynolds]

On Apr 6, 2017 3:47 PM, "Raoul Duke"  wrote:

I am writing to ignorantly sincerely ask how spec + Orchestra compares to
other statically typed out of the box JVM languages. What are the succint
wins over not Scala shudder but eg Kotlin Ceylon, heck Frege, et. al.?


i could be wrong, but i do not view spec as a type system.  more like the
dual of a type system. clojure does not do types, strictly speaking.  there
are lots of reasons to like it, but "it types" is not one of them.  spec
does not change this.

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Gregg Reynolds]

On Apr 7, 2017 12:07 AM, "Didier"  wrote:



Types are not very precise though, like it will catch 10/"123", but not
10/0, because the type isn't more precise then int.


no, this will, or at least should, be caught. 10/0 is not an int, and typed
"/' would reject 0 as an ill-typed denominator.

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Colin Yates]

Not sure where you are getting the assertion of equivalence from, it
certainly isn't what I meant. I think you missed my point, which is only
"Spec is great as we have the power of Clojure" - sure, just don't forget
you have the power of ANOther language in that language as well.

I think comparing Clojure Spec against _only_ a static typing machine to be
disingenuous, that's all.

Love, peace and goodwill to all :-).

On Friday, 7 April 2017, Didier  wrote:

> @Colin Yates
>
> If spec is a DSL to describe invariants and the static typing of other
> languages are too, then it's not true that all static typing DSLs can
> express what the spec DSL can.
>
> If you say, could I build spec in other languages, or can I put asserts in
> the code using the full languages, ya off course you can, but not without
> considerable effort. Similarly, you can add static typing to Clojure, but
> that also comes with considerable effort.
>
> That's why people skip over this. Can I embed a haskell inside Clojure? I
> could. I could embed a Clojure inside Haskell too. But those are not a
> given feature provided to me for free as standard.
>
> So the discussion should center around what features I get for free. With
> spec, you get a very powerful description DSL, more powerful than most
> static typing ones. You get generative testing, parsing, validation,
> asserts and documentation. With static typing systems, you get a often less
> powerful description DSL, compile time type assertions, and documentation.
>
> --
> 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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Didier]

@Colin Yates

If spec is a DSL to describe invariants and the static typing of other 
languages are too, then it's not true that all static typing DSLs can express 
what the spec DSL can.

If you say, could I build spec in other languages, or can I put asserts in the 
code using the full languages, ya off course you can, but not without 
considerable effort. Similarly, you can add static typing to Clojure, but that 
also comes with considerable effort.

That's why people skip over this. Can I embed a haskell inside Clojure? I 
could. I could embed a Clojure inside Haskell too. But those are not a given 
feature provided to me for free as standard. 

So the discussion should center around what features I get for free. With spec, 
you get a very powerful description DSL, more powerful than most static typing 
ones. You get generative testing, parsing, validation, asserts and 
documentation. With static typing systems, you get a often less powerful 
description DSL, compile time type assertions, and documentation. 

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Colin Yates]

So I see Clojure Spec as an "internal DSL if you squint" for
describing invariants that are enforced at runtime. Static typing is
also an "internal DSL if you squint" for describing
data-shape-invariants at compile time. With Clojure Spec you have the
entirety of Clojure to describe those invariants, with a static typing
lib you are limited to whatever constructs language provides. So
Clojure Spec is much more open and extensible in that regard.


However, I see a lot of people stopping the discussion there without
accounting for the fact that you _also_ have the "entirety of
language-X to describe those invariants" for any given language. Pre
and Post conditions have been around since the dawn of time and most
languages (I know about) have asserts. If the language has support for
AOP then even better as the description and application of those
invariants don't need to be embedded in the code in question. This
means that any given language, purely from a "can it enforce this?" is
at least as powerful as Clojure Spec.

And Clojure Spec's ability to feed the generative testing machine is
awesome if you can describe your accepted inputs in that way.

So, in terms of "can I express this invariant" in both static and
statically typed languages? Yep, of course.


Clojure Spec and static type systems are both tools for enforcing
invariants. Can Clojure Spec describe invariants that
StaticTypingLanguage-X can't? No, of course not. Is the machinery
around Clojure Spec useful - absolutely.

I have longed for a statically compiled language with type inference
with the simplicity and consistency of Clojure's syntax that also
supports generative testing and works on the JVM but alas, I have not
found one. Frege and PureScript both look interesting but I am unsure
of Frege's longevity and PureScript's performance on the JVM's
Javascript environment.

On 7 April 2017 at 06:07, Didier <didi...@gmail.com> wrote:
> It's different, yet related.
>
> Static type systems and clojure.spec both try to prevent bugs. They're tools 
> to help you write correct programs, the same way that a testing framework is. 
> Neither of them will catch all your bugs unfortunately.
>
> Static type systems catches bugs where you would try to do an operation over 
> a type which does not support it. Types are not very precise though, like it 
> will catch 10/"123", but not 10/0, because the type isn't more precise then 
> int. So int/int will be ok, but int/string will be caught at compile time as 
> a bug.
>
> The advantage of static type systems is that what they do catch, they will 
> catch 100% of the time and they generally run pretty quickly.
>
> Clojure.spec catches bugs where you'll try to do something on a value which 
> isn't acceptable, as well as catch bugs where the relationship between the 
> input and output values is wrong. So it can catch 10/0 and 10/"123". If a 
> parameter was true and functionally that means the output should be false, 
> but a bug causes it to be true instead, well it can also catch that.
>
> The disadvantage of clojure.spec is that you cannot be sure it caught 100% of 
> those bugs. It will catch some, but maybe not all. It will also be much 
> slower to run.
>
> Now, clojure.spec has one more trick up its sleeves. It can be used for 
> static analyses on steroids. If you've ever used Find bugs in java, you know 
> a little what I'm talking about. If you use Spectrum, it will try to catch 
> some of those same bugs at compile time, and it could in theory be made to 
> catch 100% of the bugs static type systems catch. Spectrum is new and not 
> fully featured yet, but so is clojure.spec, so this is a possible future 
> which you can have a taste for today. I recommend checking it out: 
> https://github.com/arohner/spectrum
>
> Alright, that's the part about catching bugs. Now there's more to it. Type 
> declarations are normally helpful documentation too, and so is clojure.spec. 
> Spec, once again, can be way more precise in documenting. Similarly, types 
> can help tooling and error messages, so can spec.
>
> Finally, spec also allows some things types don't even cover, such as parsing 
> and validation of non typed data like json. Spec can parse a complex 
> structure into an AST. It can also validate EDN, or json that was 
> unmarshalled into clojure.
>
> As time goes on, I'm sure someone will find other use cases for it too.
>
> Hope this helps.
>
> P.S.: Clojure also has a static type system called core.typed. It is not as 
> widely used though, and has only one developer working on it. It also doesn't 
> compare to the languages you listed, since it is a gradual type system, more 
> inline with typescript, typed racket and hack.
>
> --
> You received this message 

Re: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Didier]

It's different, yet related.

Static type systems and clojure.spec both try to prevent bugs. They're tools to 
help you write correct programs, the same way that a testing framework is. 
Neither of them will catch all your bugs unfortunately. 

Static type systems catches bugs where you would try to do an operation over a 
type which does not support it. Types are not very precise though, like it will 
catch 10/"123", but not 10/0, because the type isn't more precise then int. So 
int/int will be ok, but int/string will be caught at compile time as a bug.

The advantage of static type systems is that what they do catch, they will 
catch 100% of the time and they generally run pretty quickly.

Clojure.spec catches bugs where you'll try to do something on a value which 
isn't acceptable, as well as catch bugs where the relationship between the 
input and output values is wrong. So it can catch 10/0 and 10/"123". If a 
parameter was true and functionally that means the output should be false, but 
a bug causes it to be true instead, well it can also catch that.

The disadvantage of clojure.spec is that you cannot be sure it caught 100% of 
those bugs. It will catch some, but maybe not all. It will also be much slower 
to run.

Now, clojure.spec has one more trick up its sleeves. It can be used for static 
analyses on steroids. If you've ever used Find bugs in java, you know a little 
what I'm talking about. If you use Spectrum, it will try to catch some of those 
same bugs at compile time, and it could in theory be made to catch 100% of the 
bugs static type systems catch. Spectrum is new and not fully featured yet, but 
so is clojure.spec, so this is a possible future which you can have a taste for 
today. I recommend checking it out: https://github.com/arohner/spectrum

Alright, that's the part about catching bugs. Now there's more to it. Type 
declarations are normally helpful documentation too, and so is clojure.spec. 
Spec, once again, can be way more precise in documenting. Similarly, types can 
help tooling and error messages, so can spec.

Finally, spec also allows some things types don't even cover, such as parsing 
and validation of non typed data like json. Spec can parse a complex structure 
into an AST. It can also validate EDN, or json that was unmarshalled into 
clojure.

As time goes on, I'm sure someone will find other use cases for it too.

Hope this helps.

P.S.: Clojure also has a static type system called core.typed. It is not as 
widely used though, and has only one developer working on it. It also doesn't 
compare to the languages you listed, since it is a gradual type system, more 
inline with typescript, typed racket and hack.

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Timothy Baldridge]

The power offered by spec is probably better compared against dependent
type systems like Idris. True static type systems run analysis at
compile-time, but spec allows you to perform very complex checks because
you have the power of full blown language.

For example, with spec you can write a function spec that says "Union is a
function that takes two hashsets. The return value of this function is a
hashset that contains all the values found in the hashset arguments".
That's impossible to statically check in most languages. Some languages
like Idris approach this level of expressibility, but when they fall short,
you're sunk. In spec you can always pop the escape hatch and write a custom
predicate in Clojure code.

So for me that's the tradeoff. I loose compile-time checking, but gain a
*ton* of power. And since types exist at run-time we can do cool things
like introspect them and generate data, documentation, better error
messages, or even run logic over them to write a static type checker.

On Thu, Apr 6, 2017 at 2:57 PM, Jeaye <cont...@jeaye.com> wrote:

> On Thu, Apr 06, 2017 at 01:47:17PM -0700, Raoul Duke wrote:
> > I am writing to ignorantly sincerely ask how spec + Orchestra compares to
> > other statically typed out of the box JVM languages. What are the succint
> > wins over not Scala shudder but eg Kotlin Ceylon, heck Frege, et. al.?
>
> clojure.spec validates data at run-time. spec's instrumentation, and thus
> Orchestra's, checks function arguments, return values, etc _when the
> function is called_, not during AOT compilation.
>
> In contrast, a static type system would catch theses errors before the
> program itself even runs. In my opinion, clojure.spec + Orchestra still
> falls quite short of a static type system, but it's the best setup I've
> seen for automated data validation as it moves through all parts of your
> Clojure programs. Even in languages with static type systems (C++, even),
> you almost certainly won't get automatic validation of the data, for each
> function call, return, etc, given only a declarative spec. In that way,
> clojure.spec alone provides something of great value.
>
> Aside from that, you're talking about the gains of Clojure versus all of
> those languages you listed. That's not related to Orchestra and would
> likely be better answered by people more knowledgeable than me.
>
> --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Jeaye]

On Thu, Apr 06, 2017 at 01:47:17PM -0700, Raoul Duke wrote:
> I am writing to ignorantly sincerely ask how spec + Orchestra compares to
> other statically typed out of the box JVM languages. What are the succint
> wins over not Scala shudder but eg Kotlin Ceylon, heck Frege, et. al.?

clojure.spec validates data at run-time. spec's instrumentation, and thus 
Orchestra's, checks function arguments, return values, etc _when the function 
is called_, not during AOT compilation.

In contrast, a static type system would catch theses errors before the program 
itself even runs. In my opinion, clojure.spec + Orchestra still falls quite 
short of a static type system, but it's the best setup I've seen for automated 
data validation as it moves through all parts of your Clojure programs. Even in 
languages with static type systems (C++, even), you almost certainly won't get 
automatic validation of the data, for each function call, return, etc, given 
only a declarative spec. In that way, clojure.spec alone provides something of 
great value.

Aside from that, you're talking about the gains of Clojure versus all of those 
languages you listed. That's not related to Orchestra and would likely be 
better answered by people more knowledgeable than me.

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


signature.asc
Description: PGP signature

was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Raoul Duke]

I am writing to ignorantly sincerely ask how spec + Orchestra compares to
other statically typed out of the box JVM languages. What are the succint
wins over not Scala shudder but eg Kotlin Ceylon, heck Frege, et. al.?

-- 
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: Orchestra, complete instrumentation for clojure.spec

[Didier]

I think that answers my question. I just wanted an approximate idea of the 
kind of LTS this would have, before depending on it. I meant like if it 
would keep up with the changes to spec before release. So I'm glad to hear 
it will and possibly even beyond.

Thanks.

On Thursday, 6 April 2017 11:43:55 UTC-7, Jeaye wrote:
>
> On Thu, Apr 06, 2017 at 11:31:46AM -0700, Didier wrote: 
> > Looks good. May I ask, what kind of support are we looking at? Is this 
> something you reasonably see being carried to the release of 1.9? Or was it 
> more of an experiment? 
>
> I'm not entirely sure what you mean by "carried to the release of 1.9" 
> here. I don't expect that Alex, Rich, et al. will change their minds, 
> again, about clojure.spec's instrument validating :ret and :fn specs. As 
> such, I intend for Orchestra to exist up until, and well beyond, Clojure 
> 1.9. 
>
> Orchestra is an integral part of my workflow and likely the biggest 
> improvement to my Clojure toolchain, along with clojure.spec, in the past 
> few years. 
>
> Let me know if I can help any further. 
>

-- 
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: Orchestra, complete instrumentation for clojure.spec

[Jeaye]

On Thu, Apr 06, 2017 at 11:31:46AM -0700, Didier wrote:
> Looks good. May I ask, what kind of support are we looking at? Is this 
> something you reasonably see being carried to the release of 1.9? Or was it 
> more of an experiment?

I'm not entirely sure what you mean by "carried to the release of 1.9" here. I 
don't expect that Alex, Rich, et al. will change their minds, again, about 
clojure.spec's instrument validating :ret and :fn specs. As such, I intend for 
Orchestra to exist up until, and well beyond, Clojure 1.9.

Orchestra is an integral part of my workflow and likely the biggest improvement 
to my Clojure toolchain, along with clojure.spec, in the past few years.

Let me know if I can help any further.

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


signature.asc
Description: PGP signature

Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Didier]

Looks good. May I ask, what kind of support are we looking at? Is this 
something you reasonably see being carried to the release of 1.9? Or was it 
more of an experiment?

-- 
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: Orchestra, complete instrumentation for clojure.spec

[Alan Thompson]

Sounds nice! Will definitely be looking into this.
Alan

On Wed, Apr 5, 2017 at 11:21 AM, Jeaye  wrote:

> Folks,
>
> tl;dr -- https://github.com/jeaye/orchestra
>
> I'd like to announce the release of Orchestra, which tackles an
> opinionated issue of clojure.spec's instrumentation not checking :ret and
> :fn specs. For those who side against the decision to elide those checks, I
> encourage you to drop Orchestra in, with nothing but a (:require) change.
>
> In my development, since making Orchestra, _every error_ I've seen has
> been a spec error. Compared to an accidental nil somewhere, in new,
> untested code, which trickled into some other place before rearing its
> head, spec errors are superb. My workflow has since become oriented around
> writing specs for functions as I write those functions and then knowing,
> since I'm instrumenting, whenever I use it incorrectly (ever so often).
>
> Note that I'm not suggesting that Orchestra should replace the need for
> unit tests, or spec's generative testing, or any other form of test writing
> outside the scope of just running your application. Since test writing
> often happens after the fact, however, in between sprints or otherwise,
> Orchestra provides a stern look at your data as it passes through your
> Clojure machine.
>
> Best,
> Jeaye
>
> --
> 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.