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 
>> ,
>>  
>> 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: [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 
 ,
  
 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 

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

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

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