Re: [ANN] Clojure 1.9.0-alpha1

[Mark Engelberg]

On Tue, May 24, 2016 at 8:55 PM, Mark Engelberg 
wrote:

> I would like to see function in the spec namespace that returns true if
> input conforms to a spec, otherwise returns false and prints to standard
> out an explanation of the failure.  Sort of a valid-or-explain predicate
> (but a shorter name would be better).
>

My point is that this would be a useful thing to use inside a pre or post
condition.

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

[Mark Engelberg]

One thing that has always limited the value of pre and post conditions is
that they don't give useful error messages.

I would like to see function in the spec namespace that returns true if
input conforms to a spec, otherwise returns false and prints to standard
out an explanation of the failure.  Sort of a valid-or-explain predicate
(but a shorter name would be better).

In some sense, fdef is superior to using pre and post assertions, so maybe
at some point they will feel obsolete, but possibly not -- things defined
with fdef have to be explicitly instrumented, but pre and post assertions
automatically follow the behavior set for all assertions.

So as long as pre and post assertions have value, I think many people are
going to cobble together their own implementation of valid-or-explain.
Better to have one standard implementation that everyone can rely on.

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

[Ambrose Bonnaire-Sergeant]

Thanks for the guide Alex.

Is it possible to get more information in the "no method" error returned by
multi-spec?

(s/explain :event/event {:event/type :event/restart})
;; val: {:event/type :event/restart} fails predicate: my.domain/event-type,
no method

It would be nice to mention exactly which method is missing here (ie.
:event/restart).

Thanks,
Ambrose

On Tue, May 24, 2016 at 9:01 PM, Colin Fleming 
wrote:

> I'll also need a spec translator (from s/form or s/describe, I guess - I'm
> not clear on the difference), and I'm very interesting in seeing any
> details if someone gets to it before I do.
>
> Cheers,
> Colin
>
> On 25 May 2016 at 12:38, Timothy Baldridge  wrote:
>
>> The output of `spec/form` is helps a bit with this, as it namespaces
>> vars, keywords and symbols correctly. I've had it on my list to write a
>> translator for specs sometime in the near future, but I haven't done it
>> yet. True the output of `form` isn't as uniform as I would like (sexprs
>> instead of maps) but I don't think it would be too much work.
>>
>> Timothy
>>
>> On Tue, May 24, 2016 at 6:26 PM, Leif  wrote:
>>
>>> Hi, Alex, thanks for the responsiveness.
>>>
>>> The paths refer to tags in the schemas, not keys in the map. However,
 this has been asked about several times today and Rich has added support
 for a :in clause that will track the key paths to master and that will be
 in alpha2.

>>>
>>>  Where is this discussion thread?  I wouldn't want to ask duplicate
>>> questions.
>>>
>>>
 Is there a recommended way to introspect specs for our own purposes
 (coercion, code generation)?  An interpreter on the output of 'describe'
 might work (although it's a little complicated for fn specs), but I wanted
 to know if you all had any thoughts or plans for the future here.

>>>
>>>
 Could you give more details on what question you would like to ask?

>>>
>>> Better people to ask would be those that have a lot of experience
>>> writing translators for specs, like the Schema devs.  But I'll give my
>>> muddled thoughts here:
>>>
>>> Right now, the internals of different instances of Spec are private.
>>> So, to write a translator from a Spec to the approximate json or avro
>>> schema it specifies, or translate from a Spec to a function that coerces a
>>> String to a data structure that conforms, I would have to:
>>>
>>> 1. Parse the output of 'describe' back into a description of the Spec's
>>> internals (if I can get at all of them)
>>> 2. Interpret / translate the parsed tree
>>>
>>> In fact, the current Spec protocol, in my mind, is actually 4 protocols,
>>> one for 4 different translators you all have written:
>>>
>>> (defprotocol Spec
>>>   ;; Spec->Conformer
>>>   (conform* [spec x])
>>>   :: Spec->Explainer
>>>   (explain* [spec path via x])
>>>   ;; Spec->Gen
>>>   (gen* [spec overrides path rmap])
>>>   (with-gen* [spec gfn])
>>>   ;; Spec->Describer
>>>   (describe* [spec]))
>>>
>>> But this implementation hiding dooms clojure/core to write *all* the
>>> translators.  This just seems weird given how most other Clojure features
>>> are open and user-extensible.
>>>
>>> --Leif
>>>
>>> --
>>> 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.
>>
>
> --
> You received this message because you are 

[ANN] json-schema 0.7.2

[Tatu Tarvainen]

I'd like to announce a new version of json-schema.

Leiningen coordinates: [webjure/json-schema "0.7.2"]
Github: https://github.com/tatut/json-schema

The validator valdiates JSON documents against JSON schema 
(http://json-schema.org/).

There are two modes: a runtime validate function, which takes a schema and 
some JSON (and some optional options) 
and returns an error map describing the validation errors or nil if data is 
valid.
The other mode is a macro make-validator that loads the schema at compile 
time and emits a validation function for it.

The validator is tested against the JSON schema test suite for draft4 and 
passes nearly all tests.



-- 
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: Handle error many lazy sequence

[Asim Jalis]

Another option: put the try catch inside the inner loop where you are doing the 
failing operation.

> On May 19, 2016, at 5:36 AM, Fluid Dynamics  wrote:
> 
>> On Thursday, May 19, 2016 at 7:50:57 AM UTC-4, khairul isan wrote:
>> Hello all,
>> 
>> I have problem on handle many lazy sequence,
>> 
>> (try
>>(for [x [1 2 3 "b"]]
>>   (for [n [1 2 3 4]]
>> (+ x n)))
>>(catch Throwable e
>>  (pr-str e)))
>> 
>> When i handle but error not in catch.
>> Any solution ?
>> 
>> Thanks
> 
> The lazy sequence isn't being realized until after the try block exits. If 
> *both* fors are wrapped in (doall ... ) the exception gets caught, because 
> then the calculations (and the error) happen while still inside of the try 
> body.
> -- 
> 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.0-alpha1

[Colin Fleming]

I'll also need a spec translator (from s/form or s/describe, I guess - I'm
not clear on the difference), and I'm very interesting in seeing any
details if someone gets to it before I do.

Cheers,
Colin

On 25 May 2016 at 12:38, Timothy Baldridge  wrote:

> The output of `spec/form` is helps a bit with this, as it namespaces vars,
> keywords and symbols correctly. I've had it on my list to write a
> translator for specs sometime in the near future, but I haven't done it
> yet. True the output of `form` isn't as uniform as I would like (sexprs
> instead of maps) but I don't think it would be too much work.
>
> Timothy
>
> On Tue, May 24, 2016 at 6:26 PM, Leif  wrote:
>
>> Hi, Alex, thanks for the responsiveness.
>>
>> The paths refer to tags in the schemas, not keys in the map. However,
>>> this has been asked about several times today and Rich has added support
>>> for a :in clause that will track the key paths to master and that will be
>>> in alpha2.
>>>
>>
>>  Where is this discussion thread?  I wouldn't want to ask duplicate
>> questions.
>>
>>
>>> Is there a recommended way to introspect specs for our own purposes
>>> (coercion, code generation)?  An interpreter on the output of 'describe'
>>> might work (although it's a little complicated for fn specs), but I wanted
>>> to know if you all had any thoughts or plans for the future here.
>>>
>>
>>
>>> Could you give more details on what question you would like to ask?
>>>
>>
>> Better people to ask would be those that have a lot of experience writing
>> translators for specs, like the Schema devs.  But I'll give my muddled
>> thoughts here:
>>
>> Right now, the internals of different instances of Spec are private.  So,
>> to write a translator from a Spec to the approximate json or avro schema it
>> specifies, or translate from a Spec to a function that coerces a String to
>> a data structure that conforms, I would have to:
>>
>> 1. Parse the output of 'describe' back into a description of the Spec's
>> internals (if I can get at all of them)
>> 2. Interpret / translate the parsed tree
>>
>> In fact, the current Spec protocol, in my mind, is actually 4 protocols,
>> one for 4 different translators you all have written:
>>
>> (defprotocol Spec
>>   ;; Spec->Conformer
>>   (conform* [spec x])
>>   :: Spec->Explainer
>>   (explain* [spec path via x])
>>   ;; Spec->Gen
>>   (gen* [spec overrides path rmap])
>>   (with-gen* [spec gfn])
>>   ;; Spec->Describer
>>   (describe* [spec]))
>>
>> But this implementation hiding dooms clojure/core to write *all* the
>> translators.  This just seems weird given how most other Clojure features
>> are open and user-extensible.
>>
>> --Leif
>>
>> --
>> 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.
>

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

Re: [ANN] Clojure 1.9.0-alpha1

[Timothy Baldridge]

The output of `spec/form` is helps a bit with this, as it namespaces vars,
keywords and symbols correctly. I've had it on my list to write a
translator for specs sometime in the near future, but I haven't done it
yet. True the output of `form` isn't as uniform as I would like (sexprs
instead of maps) but I don't think it would be too much work.

Timothy

On Tue, May 24, 2016 at 6:26 PM, Leif  wrote:

> Hi, Alex, thanks for the responsiveness.
>
> The paths refer to tags in the schemas, not keys in the map. However, this
>> has been asked about several times today and Rich has added support for a
>> :in clause that will track the key paths to master and that will be in
>> alpha2.
>>
>
>  Where is this discussion thread?  I wouldn't want to ask duplicate
> questions.
>
>
>> Is there a recommended way to introspect specs for our own purposes
>> (coercion, code generation)?  An interpreter on the output of 'describe'
>> might work (although it's a little complicated for fn specs), but I wanted
>> to know if you all had any thoughts or plans for the future here.
>>
>
>
>> Could you give more details on what question you would like to ask?
>>
>
> Better people to ask would be those that have a lot of experience writing
> translators for specs, like the Schema devs.  But I'll give my muddled
> thoughts here:
>
> Right now, the internals of different instances of Spec are private.  So,
> to write a translator from a Spec to the approximate json or avro schema it
> specifies, or translate from a Spec to a function that coerces a String to
> a data structure that conforms, I would have to:
>
> 1. Parse the output of 'describe' back into a description of the Spec's
> internals (if I can get at all of them)
> 2. Interpret / translate the parsed tree
>
> In fact, the current Spec protocol, in my mind, is actually 4 protocols,
> one for 4 different translators you all have written:
>
> (defprotocol Spec
>   ;; Spec->Conformer
>   (conform* [spec x])
>   :: Spec->Explainer
>   (explain* [spec path via x])
>   ;; Spec->Gen
>   (gen* [spec overrides path rmap])
>   (with-gen* [spec gfn])
>   ;; Spec->Describer
>   (describe* [spec]))
>
> But this implementation hiding dooms clojure/core to write *all* the
> translators.  This just seems weird given how most other Clojure features
> are open and user-extensible.
>
> --Leif
>
> --
> 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: [ANN] Clojure 1.9.0-alpha1

[Leif]

Hi, Alex, thanks for the responsiveness.

The paths refer to tags in the schemas, not keys in the map. However, this 
> has been asked about several times today and Rich has added support for a 
> :in clause that will track the key paths to master and that will be in 
> alpha2. 
>

 Where is this discussion thread?  I wouldn't want to ask duplicate 
questions. 
 

> Is there a recommended way to introspect specs for our own purposes 
> (coercion, code generation)?  An interpreter on the output of 'describe' 
> might work (although it's a little complicated for fn specs), but I wanted 
> to know if you all had any thoughts or plans for the future here.
>
 

> Could you give more details on what question you would like to ask?
>
 
Better people to ask would be those that have a lot of experience writing 
translators for specs, like the Schema devs.  But I'll give my muddled 
thoughts here:

Right now, the internals of different instances of Spec are private.  So, 
to write a translator from a Spec to the approximate json or avro schema it 
specifies, or translate from a Spec to a function that coerces a String to 
a data structure that conforms, I would have to:

1. Parse the output of 'describe' back into a description of the Spec's 
internals (if I can get at all of them)
2. Interpret / translate the parsed tree

In fact, the current Spec protocol, in my mind, is actually 4 protocols, 
one for 4 different translators you all have written:

(defprotocol Spec
  ;; Spec->Conformer
  (conform* [spec x])
  :: Spec->Explainer
  (explain* [spec path via x])
  ;; Spec->Gen
  (gen* [spec overrides path rmap])
  (with-gen* [spec gfn])
  ;; Spec->Describer
  (describe* [spec]))

But this implementation hiding dooms clojure/core to write *all* the 
translators.  This just seems weird given how most other Clojure features 
are open and user-extensible.

--Leif

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

[Elliot]

Super super excited for this feature, thanks so much for creating this.

In the runtime-validation case, the guide mentions:

1. Calling `valid?` in a precondition
2. Calling `conform` in the fn implementation

However neither of these appear to use the `fdef`/`instrument` combo, which 
seems the closest to "type annotating" the function.  Would you ever expect 
to use fdef/instrument active in production for validation, or is that a 
misunderstanding of its use?

Thanks!

- E

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

[Elliot]

Super super excited for this feature, thanks so much for creating this.

In the runtime-validation case, the guide mentions:

1. Calling `valid?` in a precondition
2. Calling `conform` in the fn implementation

However neither of these appear to use the `fdef`/`instrument` combo, which 
seems the closest to "type annotating" the function.  Would you ever expect 
to use fdef/instrument active in production for validation, or is that a 
misunderstanding of its use?

Thanks!

- E


On Tuesday, May 24, 2016 at 11:12:59 AM UTC-7, scott stackelhouse wrote:
>
> I restructured my data to make this section an optional sub-map, which I 
> think is actually better anyway.
>
> On Tuesday, May 24, 2016 at 11:08:27 AM UTC-7, scott stackelhouse wrote:
>>
>> Ok.  
>>
>> Thanks all who have worked on this, btw.  It is incredibly timely for me 
>> and is already great help for a work project.
>>
>> --Scott
>>
>> On Tuesday, May 24, 2016 at 10:57:26 AM UTC-7, Rich Hickey wrote:
>>>
>>> ‘and' and ‘or’ are not currently supported in :opt 
>>>
>>>
>>> > On May 24, 2016, at 1:45 PM, scott stackelhouse <
>>> scott.sta...@gmail.com> wrote: 
>>> > 
>>> > I'm having a problem writing a spec for a map with some required 
>>> keywords and some optional keywords.  The caveat here is that the optional 
>>> keywords are all or none... that is they are optional but if one is present 
>>> they must all be present. 
>>> > 
>>> > What I tried to write was: 
>>> > 
>>> > (s/keys :req [::a ::b ::c] :opt [(and ::d ::e ::f)])   
>>> > 
>>> > and that fails an assertion.  It appears that the logicals (and, or) 
>>> are not allowed in the optional section? 
>>> > 
>>> > Am I thinking about this in the wrong way?   
>>> > 
>>> > --Scott 
>>> > 
>>> > -- 
>>> > You received this message because you are subscribed to the Google 
>>> > Groups "Clojure" group. 
>>> > To post to this group, send email to clo...@googlegroups.com 
>>> > Note that posts from new members are moderated - please be patient 
>>> with your first post. 
>>> > To unsubscribe from this group, send email to 
>>> > clojure+u...@googlegroups.com 
>>> > For more options, visit this group at 
>>> > http://groups.google.com/group/clojure?hl=en 
>>> > --- 
>>> > You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group. 
>>> > To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com. 
>>> > For more options, visit https://groups.google.com/d/optout. 
>>>
>>>

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

[Stan Dyck]

I appreciate the wisdom of separating the existence of a key from the 
conformance of the values of that key.


I wonder though if there is a way to specify co-constraints; a situation 
where the conformance of the value of one key depends on the existence 
of and perhaps the value of another key.


Say for example, I want to specify a ::content-type key and a ::body 
key. If the ::content-type key exists and has a value of "image/png" I 
want to make sure the ::body key also exists and satisfies my image? 
predicate.


It looks like multi-specs get me to the neighborhood of a solution here 
but I'm not sure they quite cover it.



Thanks,

StanD.


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

[Sean Corfield]

We have 1.9.0 Alpha 1 in QA at World Singles and plan to start using 
clojure.spec this week. We’ve gone to production on Alpha builds ever since 1.3 
and almost never had any problems (in five years – time has flown past!).

 

What sort of tradeoffs have you in mind regarding whether to use clojure.spec 
or not? I ask because I’m thinking about adding an optional namespace to 
clojure.java.jdbc that would provide fn-specs for that library – my assumption 
is that folks not yet using a 1.9.0 build would simply not require that spec 
namespace…

 

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood


 

On 5/24/16, 11:51 AM, "Gary Trakhman"  wrote:

 

The inevitable question: is there a release schedule for 1.9 yet? I would love 
to start writing greenfield spec code ASAP, knowing that would help me 
communicate tradeoffs.

 

 

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

[Alex Miller]

On Tuesday, May 24, 2016 at 4:54:40 PM UTC-5, Leif wrote:
>
> Spec usage guide questions:
>
> There is a small typo in the 'Collections' section (pretend this is a 
> question):
>
> (s/conform (s/coll-of number? #{} #{5 10 2}))
> ;; should be
> (s/conform (s/coll-of number? #{}) #{5 10 2})
>
>
Fixing...
 

>
> Is there a technical reason why the paths reported by 's/explain' for 
> regex ops are incomplete?  E.g., in the "A game of cards" section, I would 
> expect:
>
> (s/explain ::game ...)
> At: [::players 0 ::hand 0 1] val: :banana fails spec: ::card predicate: suit?
> ;; but the real output is this, indices from regex matches missing
> At: [::players ::hand 1] val: :banana fails spec: ::card predicate: suit?
>
>
> It's fine here, but it could get harder to find the failure point in a 
> larger data structure.
>

The paths refer to tags in the schemas, not keys in the map. However, this 
has been asked about several times today and Rich has added support for a 
:in clause that will track the key paths to master and that will be in 
alpha2. 

>
> Is there a way to write a map spec that contains *only* the required 
> keyset?  This is against the spirit of the 'composition' arguments in the 
> Rationale, but sometimes I really want to pin down the exact data in a map, 
> especially for data about to escape into the wild (e.g. return values of a 
> web API).
>

Nothing built in, but it's easy enough to write that predicate yourself if 
you need it.
 

> The behavior of 's/and' really surprised me (again, pretend this is a 
> question).  The conformed values propagating through is semantically weird 
> when you have 'core/and' in mind.  Also, if you have data keywords and spec 
> keywords, it could get complicated to keep track of what's what in the 
> later specs.  More examples in the "Composing predicates" section, right 
> when 's/and' in introduced, might take away the surprise and replace it 
> with luxurious comfort.
>

I'll consider it.
 

> Is there a recommended way to introspect specs for our own purposes 
> (coercion, code generation)?  An interpreter on the output of 'describe' 
> might work (although it's a little complicated for fn specs), but I wanted 
> to know if you all had any thoughts or plans for the future here.
>

Could you give more details on what question you would like to ask?
 

>
> Thanks,
> Leif
>
> On Tuesday, May 24, 2016 at 1:04:45 PM UTC-4, Alex Miller wrote:
>>
>> Clojure 1.9.0-alpha1 is now available.
>>
>> Try it via
>> - Download: 
>> https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha1
>> - Leiningen: [org.clojure/clojure "1.8.0-alpha2"]
>>
>> 1.9.0-alpha1 includes the first release of clojure.spec 
>> .
>>
>> A usage guide for spec is now available: http://clojure.org/guides/spec.
>>
>> Enjoy!
>> Alex
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Clojure 1.9.0-alpha1

[Leif]

Spec usage guide questions:

There is a small typo in the 'Collections' section (pretend this is a 
question):

(s/conform (s/coll-of number? #{} #{5 10 2}))
;; should be
(s/conform (s/coll-of number? #{}) #{5 10 2})


Is there a technical reason why the paths reported by 's/explain' for regex 
ops are incomplete?  E.g., in the "A game of cards" section, I would expect:

(s/explain ::game ...)
At: [::players 0 ::hand 0 1] val: :banana fails spec: ::card predicate: suit?
;; but the real output is this, indices from regex matches missing
At: [::players ::hand 1] val: :banana fails spec: ::card predicate: suit?


It's fine here, but it could get harder to find the failure point in a 
larger data structure.

Is there a way to write a map spec that contains *only* the required 
keyset?  This is against the spirit of the 'composition' arguments in the 
Rationale, but sometimes I really want to pin down the exact data in a map, 
especially for data about to escape into the wild (e.g. return values of a 
web API).

The behavior of 's/and' really surprised me (again, pretend this is a 
question).  The conformed values propagating through is semantically weird 
when you have 'core/and' in mind.  Also, if you have data keywords and spec 
keywords, it could get complicated to keep track of what's what in the 
later specs.  More examples in the "Composing predicates" section, right 
when 's/and' in introduced, might take away the surprise and replace it 
with luxurious comfort.

Is there a recommended way to introspect specs for our own purposes 
(coercion, code generation)?  An interpreter on the output of 'describe' 
might work (although it's a little complicated for fn specs), but I wanted 
to know if you all had any thoughts or plans for the future here.

Thanks,
Leif

On Tuesday, May 24, 2016 at 1:04:45 PM UTC-4, Alex Miller wrote:
>
> Clojure 1.9.0-alpha1 is now available.
>
> Try it via
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha1
> - Leiningen: [org.clojure/clojure "1.8.0-alpha2"]
>
> 1.9.0-alpha1 includes the first release of clojure.spec 
> .
>
> A usage guide for spec is now available: http://clojure.org/guides/spec.
>
> Enjoy!
> Alex
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] Pink 0.3.0

[Steven Yi]

Hi All,

I'd like to announce the release of Pink 0.3.0:

https://clojars.org/kunstmusik/pink
[kunstmusik/pink "0.3.0"]

Pink is an audio engine library for making music systems and compositions.

The ChangeLog is available at:

https://github.com/kunstmusik/pink/blob/master/CHANGELOG.md

This release introduces Pink processes. It reuses the state machine
macro system from core.async to allow writing event generation code
using loops and waits.  The state machine execution is wrapped in a
Pink control function and run synchronously with the engine.  Waits
may wait upon a given time value in seconds, a Pink Signal (i.e. cues
or latches), or upon a predicate function.  The use of signals and
predicates provides a means for interprocess communication, enabling
things like Lutoslawski-style aleatory (i.e., ad libitum writing)
where performers and conductors signal one other.  Further information
is available in the documentation for processes [1] and example code
is shown in [2]. (For those unfamiliar with Lutoslawski's writing, the
performance instructions given at the bottom of pages 1 and 2 of his
3rd Symphony [3] may shed some light.)

This release also provides a translation of Scott Van Duyne's piano
model from Common Lisp Music, biquad-based filters, and a number of
other audio, control, and utility functions.

Many thanks to Timothy Baldridge and other core.async contributors for
making the core.async ioc_macros easily extensible and reusable, and
again to Tim for the wonderfully clear videos on YouTube explaining
the design of the macros.

Thanks!
steven


[1] - https://github.com/kunstmusik/pink/blob/master/doc/processes.md
[2] - 
https://github.com/kunstmusik/music-examples/blob/master/src/music_examples/processes.clj
[3] - https://issuu.com/scoresondemand/docs/symphony_no3_7711

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

[Alex Miller]

Yes, I'll add that in the next deploy. Thanks.

On Tuesday, May 24, 2016 at 2:45:39 PM UTC-5, Nando Breiter wrote:
>
> Alex,
>
> The spec usage guide is excellent! Thank you!
>
> Perhaps a small correction? Below the example:
>
> (s/valid? ::person {::first-name "Elon" ::last-name "Musk" ::email "
> e...@example.com"})
>
> ;; Fails required key check
>
> You might want to include what that spec call returns under it, which I 
> assume would be *true*. I got a little confused trying to figure out why 
> you were saying it was failing ... until I figured out the comment applied 
> to the next example. 
>
>

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

[Nando Breiter]

Alex,

The spec usage guide is excellent! Thank you!

Perhaps a small correction? Below the example:

(s/valid? ::person {::first-name "Elon" ::last-name "Musk" ::email "
e...@example.com"})

;; Fails required key check

You might want to include what that spec call returns under it, which I
assume would be *true*. I got a little confused trying to figure out why
you were saying it was failing ... until I figured out the comment applied
to the next example.






Aria Media Sagl
+41 (0)76 303 4477 cell
skype: ariamedia

On Tue, May 24, 2016 at 9:13 PM, Alex Miller  wrote:

> No. I would expect on the order of months.
>
> On Tuesday, May 24, 2016 at 1:52:12 PM UTC-5, Gary Trakhman wrote:
>>
>> The inevitable question: is there a release schedule for 1.9 yet? I would
>> love to start writing greenfield spec code ASAP, knowing that would help me
>> communicate tradeoffs.
>>
> --
> 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.0-alpha1

[Alex Miller]

No. I would expect on the order of months.

On Tuesday, May 24, 2016 at 1:52:12 PM UTC-5, Gary Trakhman wrote:
>
> The inevitable question: is there a release schedule for 1.9 yet? I would 
> love to start writing greenfield spec code ASAP, knowing that would help me 
> communicate tradeoffs.
>

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

[Rich Hickey]

Fixed on master, thanks for the report.

> On May 24, 2016, at 2:05 PM, Ambrose Bonnaire-Sergeant 
>  wrote:
> 
> Thanks Rich. Now it seems test.check is eager to generate very large 
> individual samples, which sounds
> like a different problem. 
> 
> (s/def ::a (s/nilable (s/cat :a ::a
>  :b ::b
>  :c ::c)))
> (s/def ::b (s/nilable (s/cat :a ::a
>  :b ::b
>  :c ::c)))
> (s/def ::c (s/nilable (s/cat :a ::a
>  :b ::b
>  :c ::c)))
> (time
>   (count
> (binding [s/*recursion-limit* 2]
>   (gen/sample (s/gen ::a) 3
> ;"Elapsed time: 50106.721779 msecs"
> 3
> 
> Thanks,
> Ambrose
> 
> 
> On Tue, May 24, 2016 at 1:25 PM, Rich Hickey  wrote:
> And now, in the alpha release branching gens *are* lazy, so gen calls on 
> recursive specs are fast.
> 
> > On May 23, 2016, at 6:49 PM, Rich Hickey  wrote:
> >
> > Currently gens are not lazy, so entire tree is generated. This is because 
> > a) test.check isn’t lazy either and b) we want errors when asking for gen, 
> > not using it. But it is rough for recursive specs as you see.
> >
> > For now you can limit the recursion depth to control the branching:
> >
> > (binding [s/*recursion-limit* 3]
> >  (time (s/gen ::a)))
> >
> >
> >> On May 23, 2016, at 6:34 PM, Ambrose Bonnaire-Sergeant 
> >>  wrote:
> >>
> >> I'm observing mutually recursive regex ops taking a long time to generate
> >> test.check generators. Is this expected?
> >>
> >> (s/def ::a (s/nilable (s/cat :a ::a
> >> :b ::b
> >> :c ::c)))
> >> (s/def ::b (s/nilable (s/cat :a ::a
> >> :b ::b
> >> :c ::c)))
> >> (s/def ::c (s/nilable (s/cat :a ::a
> >> :b ::b
> >> :c ::c)))
> >>
> >> (time (s/gen ::a))
> >> ;"Elapsed time: 3993.431793 msecs"
> >> nil
> >>
> >> Thanks,
> >> Ambrose
> >>
> >>
> >> On Mon, May 23, 2016 at 6:12 PM, Nicola Mometto  
> >> wrote:
> >> Looks like it is, in the meanwhile this patch should fix it: 
> >> http://sprunge.us/XTiA
> >>
> >>
> >>> On 23 May 2016, at 23:03, Nicola Mometto  wrote:
> >>>
> >>> Possibly CLJ-1544 related?
> >>>
>  On 23 May 2016, at 22:59, Ambrose Bonnaire-Sergeant 
>   wrote:
> 
>  I'm having trouble calling `s/gen`, might be some sort of AOT 
>  compilation error.
>  (I'm guessing this line has something to do with it).
> 
>  I'm using the latest master-SNAPSHOT.
> 
>  (ns gen-load.core
>  (:require [clojure.spec :as s]))
> 
>  (s/gen integer?)
>  ;CompilerException java.lang.NoClassDefFoundError: 
>  clojure/spec/gen$gen_for_pred, compiling:(gen_load/core.clj:4:1)
> 
>  Thanks,
>  Ambrose
> 
>  On Mon, May 23, 2016 at 5:33 PM, Ambrose Bonnaire-Sergeant 
>   wrote:
>  I see, thanks.
> 
>  On Mon, May 23, 2016 at 5:29 PM, Rich Hickey  
>  wrote:
>  fdef will not add doc metadata (see rationale re: not putting more stuff 
>  in the namespaces/vars), but specs will be present when you call ‘doc’. 
>  That doc enhancement was in a push later in the afternoon.
> 
>  https://github.com/clojure/clojure/commit/4c8efbc42efa22ec1d08a1e9fa5dd25db99766a9
> 
> > On May 23, 2016, at 5:26 PM, Ambrose Bonnaire-Sergeant 
> >  wrote:
> >
> > Thanks Rich+team, this is awesome.
> >
> > Instrumented vars via `fdef` do not seem to add :doc metadata yet
> > (which is advertised in the docstring for `fdef`).
> >
> > Am I missing something?
> >
> > Thanks,
> > Ambrose
> >
> > On Mon, May 23, 2016 at 5:20 PM, Andrey Grin  
> > wrote:
> > Thank you. Yes, it seems that for recursion I can use the same 
> > approach. As for inheritance currently I just include all parent 
> > attributes in every child schema. As for spec definition multi-spec, as 
> > I understand it, requires "defmethod" for every class which is probably 
> > a problem for my case since all inheritance hierarchies are also 
> > determined at run-time. I will need to find some approach that is both 
> > dynamic and supports precise error messages in case validation fails.
> >
> >
> > Am Montag, 23. Mai 2016 22:38:24 UTC+2 schrieb Alex Miller:
> > I think you could apply the same idea - use a regular translation 
> > between Java class and registered name and then always refer to the 
> > registered name.
> >
> > There are probably multiple approaches to modeling 

Re: [ANN] Clojure 1.9.0-alpha1

[Gary Trakhman]

The inevitable question: is there a release schedule for 1.9 yet? I would
love to start writing greenfield spec code ASAP, knowing that would help me
communicate tradeoffs.

On Tue, May 24, 2016 at 1:05 PM Alex Miller  wrote:

> You know how you always see the typo right after you hit send?
>
> - Leiningen: [org.clojure/clojure "1.9.0-alpha1"]
>
>
> On Tuesday, May 24, 2016 at 12:04:45 PM UTC-5, Alex Miller wrote:
>>
>> Clojure 1.9.0-alpha1 is now available.
>>
>> Try it via
>> - Download:
>> https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha1
>> - Leiningen: [org.clojure/clojure "1.8.0-alpha2"]
>>
>> 1.9.0-alpha1 includes the first release of clojure.spec
>> .
>>
>> A usage guide for spec is now available: http://clojure.org/guides/spec.
>>
>> Enjoy!
>> Alex
>>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[scott stackelhouse]

I restructured my data to make this section an optional sub-map, which I 
think is actually better anyway.

On Tuesday, May 24, 2016 at 11:08:27 AM UTC-7, scott stackelhouse wrote:
>
> Ok.  
>
> Thanks all who have worked on this, btw.  It is incredibly timely for me 
> and is already great help for a work project.
>
> --Scott
>
> On Tuesday, May 24, 2016 at 10:57:26 AM UTC-7, Rich Hickey wrote:
>>
>> ‘and' and ‘or’ are not currently supported in :opt 
>>
>>
>> > On May 24, 2016, at 1:45 PM, scott stackelhouse  
>> wrote: 
>> > 
>> > I'm having a problem writing a spec for a map with some required 
>> keywords and some optional keywords.  The caveat here is that the optional 
>> keywords are all or none... that is they are optional but if one is present 
>> they must all be present. 
>> > 
>> > What I tried to write was: 
>> > 
>> > (s/keys :req [::a ::b ::c] :opt [(and ::d ::e ::f)])   
>> > 
>> > and that fails an assertion.  It appears that the logicals (and, or) 
>> are not allowed in the optional section? 
>> > 
>> > Am I thinking about this in the wrong way?   
>> > 
>> > --Scott 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> > Groups "Clojure" group. 
>> > To post to this group, send email to clo...@googlegroups.com 
>> > Note that posts from new members are moderated - please be patient with 
>> your first post. 
>> > To unsubscribe from this group, send email to 
>> > clojure+u...@googlegroups.com 
>> > For more options, visit this group at 
>> > http://groups.google.com/group/clojure?hl=en 
>> > --- 
>> > You received this message because you are subscribed to the Google 
>> Groups "Clojure" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an email to clojure+u...@googlegroups.com. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>>

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

[scott stackelhouse]

Ok.  

Thanks all who have worked on this, btw.  It is incredibly timely for me 
and is already great help for a work project.

--Scott

On Tuesday, May 24, 2016 at 10:57:26 AM UTC-7, Rich Hickey wrote:
>
> ‘and' and ‘or’ are not currently supported in :opt 
>
>
> > On May 24, 2016, at 1:45 PM, scott stackelhouse  > wrote: 
> > 
> > I'm having a problem writing a spec for a map with some required 
> keywords and some optional keywords.  The caveat here is that the optional 
> keywords are all or none... that is they are optional but if one is present 
> they must all be present. 
> > 
> > What I tried to write was: 
> > 
> > (s/keys :req [::a ::b ::c] :opt [(and ::d ::e ::f)])   
> > 
> > and that fails an assertion.  It appears that the logicals (and, or) are 
> not allowed in the optional section? 
> > 
> > Am I thinking about this in the wrong way?   
> > 
> > --Scott 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com 
>  
> > Note that posts from new members are moderated - please be patient with 
> your first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com  
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
> > --- 
> > You received this message because you are subscribed to the Google 
> Groups "Clojure" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to clojure+u...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>
>

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

[Ambrose Bonnaire-Sergeant]

Thanks Rich. Now it seems test.check is eager to generate very large
individual samples, which sounds
like a different problem.

(s/def ::a (s/nilable (s/cat :a ::a
 :b ::b
 :c ::c)))
(s/def ::b (s/nilable (s/cat :a ::a
 :b ::b
 :c ::c)))
(s/def ::c (s/nilable (s/cat :a ::a
 :b ::b
 :c ::c)))
(time
  (count
(binding [s/*recursion-limit* 2]
  (gen/sample (s/gen ::a) 3
;"Elapsed time: 50106.721779 msecs"
3

Thanks,
Ambrose


On Tue, May 24, 2016 at 1:25 PM, Rich Hickey  wrote:

> And now, in the alpha release branching gens *are* lazy, so gen calls on
> recursive specs are fast.
>
> > On May 23, 2016, at 6:49 PM, Rich Hickey  wrote:
> >
> > Currently gens are not lazy, so entire tree is generated. This is
> because a) test.check isn’t lazy either and b) we want errors when asking
> for gen, not using it. But it is rough for recursive specs as you see.
> >
> > For now you can limit the recursion depth to control the branching:
> >
> > (binding [s/*recursion-limit* 3]
> >  (time (s/gen ::a)))
> >
> >
> >> On May 23, 2016, at 6:34 PM, Ambrose Bonnaire-Sergeant <
> abonnaireserge...@gmail.com> wrote:
> >>
> >> I'm observing mutually recursive regex ops taking a long time to
> generate
> >> test.check generators. Is this expected?
> >>
> >> (s/def ::a (s/nilable (s/cat :a ::a
> >> :b ::b
> >> :c ::c)))
> >> (s/def ::b (s/nilable (s/cat :a ::a
> >> :b ::b
> >> :c ::c)))
> >> (s/def ::c (s/nilable (s/cat :a ::a
> >> :b ::b
> >> :c ::c)))
> >>
> >> (time (s/gen ::a))
> >> ;"Elapsed time: 3993.431793 msecs"
> >> nil
> >>
> >> Thanks,
> >> Ambrose
> >>
> >>
> >> On Mon, May 23, 2016 at 6:12 PM, Nicola Mometto 
> wrote:
> >> Looks like it is, in the meanwhile this patch should fix it:
> http://sprunge.us/XTiA
> >>
> >>
> >>> On 23 May 2016, at 23:03, Nicola Mometto  wrote:
> >>>
> >>> Possibly CLJ-1544 related?
> >>>
>  On 23 May 2016, at 22:59, Ambrose Bonnaire-Sergeant <
> abonnaireserge...@gmail.com> wrote:
> 
>  I'm having trouble calling `s/gen`, might be some sort of AOT
> compilation error.
>  (I'm guessing this line has something to do with it).
> 
>  I'm using the latest master-SNAPSHOT.
> 
>  (ns gen-load.core
>  (:require [clojure.spec :as s]))
> 
>  (s/gen integer?)
>  ;CompilerException java.lang.NoClassDefFoundError:
> clojure/spec/gen$gen_for_pred, compiling:(gen_load/core.clj:4:1)
> 
>  Thanks,
>  Ambrose
> 
>  On Mon, May 23, 2016 at 5:33 PM, Ambrose Bonnaire-Sergeant <
> abonnaireserge...@gmail.com> wrote:
>  I see, thanks.
> 
>  On Mon, May 23, 2016 at 5:29 PM, Rich Hickey 
> wrote:
>  fdef will not add doc metadata (see rationale re: not putting more
> stuff in the namespaces/vars), but specs will be present when you call
> ‘doc’. That doc enhancement was in a push later in the afternoon.
> 
> 
> https://github.com/clojure/clojure/commit/4c8efbc42efa22ec1d08a1e9fa5dd25db99766a9
> 
> > On May 23, 2016, at 5:26 PM, Ambrose Bonnaire-Sergeant <
> abonnaireserge...@gmail.com> wrote:
> >
> > Thanks Rich+team, this is awesome.
> >
> > Instrumented vars via `fdef` do not seem to add :doc metadata yet
> > (which is advertised in the docstring for `fdef`).
> >
> > Am I missing something?
> >
> > Thanks,
> > Ambrose
> >
> > On Mon, May 23, 2016 at 5:20 PM, Andrey Grin 
> wrote:
> > Thank you. Yes, it seems that for recursion I can use the same
> approach. As for inheritance currently I just include all parent attributes
> in every child schema. As for spec definition multi-spec, as I understand
> it, requires "defmethod" for every class which is probably a problem for my
> case since all inheritance hierarchies are also determined at run-time. I
> will need to find some approach that is both dynamic and supports precise
> error messages in case validation fails.
> >
> >
> > Am Montag, 23. Mai 2016 22:38:24 UTC+2 schrieb Alex Miller:
> > I think you could apply the same idea - use a regular translation
> between Java class and registered name and then always refer to the
> registered name.
> >
> > There are probably multiple approaches to modeling inheritance, so
> hard to recommend something without knowing more. In general, attributes
> coming from super classes can be modeled using the parent attribute name.
> And I would recommend looking into multi-spec for doing validation of a
> number of "types" that could be flowing into the same location by
> leveraging a 

Re: clojure.spec

[Rich Hickey]

‘and' and ‘or’ are not currently supported in :opt


> On May 24, 2016, at 1:45 PM, scott stackelhouse 
>  wrote:
> 
> I'm having a problem writing a spec for a map with some required keywords and 
> some optional keywords.  The caveat here is that the optional keywords are 
> all or none... that is they are optional but if one is present they must all 
> be present.
> 
> What I tried to write was:
> 
> (s/keys :req [::a ::b ::c] :opt [(and ::d ::e ::f)])  
> 
> and that fails an assertion.  It appears that the logicals (and, or) are not 
> allowed in the optional section?
> 
> Am I thinking about this in the wrong way?  
> 
> --Scott
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: clojure.spec

[scott stackelhouse]

I'm having a problem writing a spec for a map with some required keywords 
and some optional keywords.  The caveat here is that the optional keywords 
are all or none... that is they are optional but if one is present they 
must all be present.

What I tried to write was:

(s/keys :req [::a ::b ::c] :opt [(and ::d ::e ::f)])  

and that fails an assertion.  It appears that the logicals (and, or) are 
not allowed in the optional section?

Am I thinking about this in the wrong way?  

--Scott

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: clojure.spec

[Rich Hickey]

And now, in the alpha release branching gens *are* lazy, so gen calls on 
recursive specs are fast.

> On May 23, 2016, at 6:49 PM, Rich Hickey  wrote:
> 
> Currently gens are not lazy, so entire tree is generated. This is because a) 
> test.check isn’t lazy either and b) we want errors when asking for gen, not 
> using it. But it is rough for recursive specs as you see.
> 
> For now you can limit the recursion depth to control the branching:
> 
> (binding [s/*recursion-limit* 3]
>  (time (s/gen ::a)))
> 
> 
>> On May 23, 2016, at 6:34 PM, Ambrose Bonnaire-Sergeant 
>>  wrote:
>> 
>> I'm observing mutually recursive regex ops taking a long time to generate
>> test.check generators. Is this expected?
>> 
>> (s/def ::a (s/nilable (s/cat :a ::a
>> :b ::b
>> :c ::c)))
>> (s/def ::b (s/nilable (s/cat :a ::a
>> :b ::b
>> :c ::c)))
>> (s/def ::c (s/nilable (s/cat :a ::a
>> :b ::b
>> :c ::c)))
>> 
>> (time (s/gen ::a))
>> ;"Elapsed time: 3993.431793 msecs"
>> nil
>> 
>> Thanks,
>> Ambrose
>> 
>> 
>> On Mon, May 23, 2016 at 6:12 PM, Nicola Mometto  wrote:
>> Looks like it is, in the meanwhile this patch should fix it: 
>> http://sprunge.us/XTiA
>> 
>> 
>>> On 23 May 2016, at 23:03, Nicola Mometto  wrote:
>>> 
>>> Possibly CLJ-1544 related?
>>> 
 On 23 May 2016, at 22:59, Ambrose Bonnaire-Sergeant 
  wrote:
 
 I'm having trouble calling `s/gen`, might be some sort of AOT compilation 
 error.
 (I'm guessing this line has something to do with it).
 
 I'm using the latest master-SNAPSHOT.
 
 (ns gen-load.core
 (:require [clojure.spec :as s]))
 
 (s/gen integer?)
 ;CompilerException java.lang.NoClassDefFoundError: 
 clojure/spec/gen$gen_for_pred, compiling:(gen_load/core.clj:4:1)
 
 Thanks,
 Ambrose
 
 On Mon, May 23, 2016 at 5:33 PM, Ambrose Bonnaire-Sergeant 
  wrote:
 I see, thanks.
 
 On Mon, May 23, 2016 at 5:29 PM, Rich Hickey  wrote:
 fdef will not add doc metadata (see rationale re: not putting more stuff 
 in the namespaces/vars), but specs will be present when you call ‘doc’. 
 That doc enhancement was in a push later in the afternoon.
 
 https://github.com/clojure/clojure/commit/4c8efbc42efa22ec1d08a1e9fa5dd25db99766a9
 
> On May 23, 2016, at 5:26 PM, Ambrose Bonnaire-Sergeant 
>  wrote:
> 
> Thanks Rich+team, this is awesome.
> 
> Instrumented vars via `fdef` do not seem to add :doc metadata yet
> (which is advertised in the docstring for `fdef`).
> 
> Am I missing something?
> 
> Thanks,
> Ambrose
> 
> On Mon, May 23, 2016 at 5:20 PM, Andrey Grin  
> wrote:
> Thank you. Yes, it seems that for recursion I can use the same approach. 
> As for inheritance currently I just include all parent attributes in 
> every child schema. As for spec definition multi-spec, as I understand 
> it, requires "defmethod" for every class which is probably a problem for 
> my case since all inheritance hierarchies are also determined at 
> run-time. I will need to find some approach that is both dynamic and 
> supports precise error messages in case validation fails.
> 
> 
> Am Montag, 23. Mai 2016 22:38:24 UTC+2 schrieb Alex Miller:
> I think you could apply the same idea - use a regular translation between 
> Java class and registered name and then always refer to the registered 
> name.
> 
> There are probably multiple approaches to modeling inheritance, so hard 
> to recommend something without knowing more. In general, attributes 
> coming from super classes can be modeled using the parent attribute name. 
> And I would recommend looking into multi-spec for doing validation of a 
> number of "types" that could be flowing into the same location by 
> leveraging a multimethod that conditionally provides the spec to use.
> 
> On Monday, May 23, 2016 at 3:09:46 PM UTC-5, Andrey Grin wrote:
> Thanks, Alex. I've taken random example from plumatic.schema wiki to 
> quickly illustrate the question. In my actual use case I dynamically 
> generate schemas based on hundreds of model Java classes (beans) with 
> mutual references so I need recursion (and also some way to model 
> inheritance, that was is achieved with "conditional" in plumatic). Will 
> try to implement the same with spec.
> 
> 
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to 

Re: clojure.spec

[JvJ]

So happy that there's now a standard way to do this!  It sounds like it 
would help with my latest project.

Unfortunately, my latest project is called "SPECS" so I guess I'll have 
to find a different name.

On Monday, 23 May 2016 07:12:29 UTC-7, Rich Hickey wrote:
>
> Introducing clojure.spec 
>
> I'm happy to introduce today clojure.spec, a new core library and support 
> for data and function specifications in Clojure. 
>
> Better communication 
>
> Clojure is a dynamic language, and thus far we have relied on 
> documentation or external libraries to explain the use and behavior of 
> functions and libraries. But documentation is difficult to produce, is 
> frequently not maintained, cannot be automatically checked and varies 
> greatly in quality. Specs are expressive and precise. Including spec in 
> Clojure creates a lingua franca with which we can state how our programs 
> work and how to use them. 
>
> More leverage and power 
>
> A key advantage of specifications over documentation is the leverage they 
> provide. In particular, specs can be utilized by programs in ways that docs 
> cannot. Defining specs takes effort, and spec aims to maximize the return 
> you get from making that effort. spec gives you tools for leveraging specs 
> in documentation, validation, error reporting, destructuring, 
> instrumentation, test-data generation and generative testing. 
>
> Improved developer experience 
>
> Error messages from macros are a perennial challenge for new (and 
> experienced) users of Clojure. specs can be used to conform data in macros 
> instead of using a custom parser. And Clojure's macro expansion will 
> automatically use specs, when present, to explain errors to users. This 
> should result in a greatly improved experience for users when errors occur. 
>
> More robust software 
>
> Clojure has always been about simplifying the development of robust 
> software. In all languages, dynamic or not, tests are essential to quality 
> - too many critical properties are not captured by common type systems. 
> spec has been designed from the ground up to directly support generative 
> testing via test.check https://github.com/clojure/test.check. When you 
> use spec you get generative tests for free. 
>
> Taken together, I think the features of spec demonstrate the ongoing 
> advantages of a powerful dynamic language like Clojure for building robust 
> software - superior expressivity, instrumentation-enhanced REPL-driven 
> development, sophisticated testing and more flexible systems. I encourage 
> you to read the spec rationale and overview  http://clojure.org/about/spec. 
> Look for spec's inclusion in the next alpha release of Clojure, within a 
> day or so. 
>
> Note that spec is still alpha, and some details are likely to change. 
> Feedback welcome. 
>
> I hope you find spec useful and powerful! 
>
> Rich 
>
>

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

[Alex Miller]

You know how you always see the typo right after you hit send?

- Leiningen: [org.clojure/clojure "1.9.0-alpha1"]

On Tuesday, May 24, 2016 at 12:04:45 PM UTC-5, Alex Miller wrote:
>
> Clojure 1.9.0-alpha1 is now available.
>
> Try it via
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha1
> - Leiningen: [org.clojure/clojure "1.8.0-alpha2"]
>
> 1.9.0-alpha1 includes the first release of clojure.spec 
> .
>
> A usage guide for spec is now available: http://clojure.org/guides/spec.
>
> Enjoy!
> Alex
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] Clojure 1.9.0-alpha1

[Alex Miller]

Clojure 1.9.0-alpha1 is now available.

Try it via
- Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha1
- Leiningen: [org.clojure/clojure "1.8.0-alpha2"]

1.9.0-alpha1 includes the first release of clojure.spec 
.

A usage guide for spec is now available: http://clojure.org/guides/spec.

Enjoy!
Alex

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Cells aka Dataflow aka FRP now pure CLJC

[hiskennyness]

Last week was supposed to be a port from a Clojure version to a CLJS 
version but for the heck of it I did it all in CLJC and (OMG) I now have my 
cherished little project running either 
way: https://github.com/kennytilton/rube

Yes, that is my third and last home for the beast.

Clojure: lein test
Clojurescript: lein cljsbuild test

Same code, same substantial tests. Full marks to the Clojure team for 
making it possible.

-hk

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

[Steve Miner]

> On May 24, 2016, at 8:10 AM, Alex Miller  wrote:
> 
> The first use is a namespace alias and the second is a var - they don't 
> overlap in usage.

Right, but it’s still a potential source of confusion.  The explanation 
distracts from the point of the example which is to demonstrate the new spec 
feature.

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

[Atamert Ölçgen]

Thanks Alex! I didn't know this.

On Tue, May 24, 2016 at 3:10 PM, Alex Miller  wrote:

> The first use is a namespace alias and the second is a var - they don't
> overlap in usage.
>
>
> On Tuesday, May 24, 2016 at 2:28:11 AM UTC-5, Atamert Ölçgen wrote:
>>
>> Isn't s redefined in this example:
>>
>> user=> (require '[clojure.spec :as s])
>> (s/def ::even? (s/and integer? even?))
>> (s/def ::odd? (s/and integer? odd?))
>> (s/def ::a integer?)
>> (s/def ::b integer?)
>> (s/def ::c integer?)
>> (def s (s/cat :forty-two #{42}
>>   :odds (s/+ ::odd?)
>>   :m (s/keys :req-un [::a ::b ::c])
>>   :oes (s/* (s/cat :o ::odd? :e ::even?))
>>   :ex (s/alt :odd ::odd? :even ::even?)))
>> user=> (s/conform s [42 11 13 15 {:a 1 :b 2 :c 3} 1 2 3 42 43 44 11])
>> {:forty-two 42,
>>  :odds [11 13 15],
>>  :m {:a 1, :b 2, :c 3},
>>  :oes [{:o 1, :e 2} {:o 3, :e 42} {:o 43, :e 44}],
>>  :ex {:odd 11}}
>>
>>
>> in http://clojure.org/about/spec
>>
>>
>> On Mon, May 23, 2016 at 5:12 PM, Rich Hickey 
>> wrote:
>>
>>> Introducing clojure.spec
>>>
>>> I'm happy to introduce today clojure.spec, a new core library and
>>> support for data and function specifications in Clojure.
>>>
>>> Better communication
>>>
>>> Clojure is a dynamic language, and thus far we have relied on
>>> documentation or external libraries to explain the use and behavior of
>>> functions and libraries. But documentation is difficult to produce, is
>>> frequently not maintained, cannot be automatically checked and varies
>>> greatly in quality. Specs are expressive and precise. Including spec in
>>> Clojure creates a lingua franca with which we can state how our programs
>>> work and how to use them.
>>>
>>> More leverage and power
>>>
>>> A key advantage of specifications over documentation is the leverage
>>> they provide. In particular, specs can be utilized by programs in ways that
>>> docs cannot. Defining specs takes effort, and spec aims to maximize the
>>> return you get from making that effort. spec gives you tools for leveraging
>>> specs in documentation, validation, error reporting, destructuring,
>>> instrumentation, test-data generation and generative testing.
>>>
>>> Improved developer experience
>>>
>>> Error messages from macros are a perennial challenge for new (and
>>> experienced) users of Clojure. specs can be used to conform data in macros
>>> instead of using a custom parser. And Clojure's macro expansion will
>>> automatically use specs, when present, to explain errors to users. This
>>> should result in a greatly improved experience for users when errors occur.
>>>
>>> More robust software
>>>
>>> Clojure has always been about simplifying the development of robust
>>> software. In all languages, dynamic or not, tests are essential to quality
>>> - too many critical properties are not captured by common type systems.
>>> spec has been designed from the ground up to directly support generative
>>> testing via test.check https://github.com/clojure/test.check. When you
>>> use spec you get generative tests for free.
>>>
>>> Taken together, I think the features of spec demonstrate the ongoing
>>> advantages of a powerful dynamic language like Clojure for building robust
>>> software - superior expressivity, instrumentation-enhanced REPL-driven
>>> development, sophisticated testing and more flexible systems. I encourage
>>> you to read the spec rationale and overview
>>> http://clojure.org/about/spec. Look for spec's inclusion in the next
>>> alpha release of Clojure, within a day or so.
>>>
>>> Note that spec is still alpha, and some details are likely to change.
>>> Feedback welcome.
>>>
>>> I hope you find spec useful and powerful!
>>>
>>> Rich
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>> Kind Regards,
>> Atamert Ölçgen
>>
>> ◻◼◻
>> ◻◻◼
>> ◼◼◼
>>
>> www.muhuk.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, 

Re: clojure.spec

[Alex Miller]

The first use is a namespace alias and the second is a var - they don't 
overlap in usage.

On Tuesday, May 24, 2016 at 2:28:11 AM UTC-5, Atamert Ölçgen wrote:
>
> Isn't s redefined in this example:
>
> user=> (require '[clojure.spec :as s])
> (s/def ::even? (s/and integer? even?))
> (s/def ::odd? (s/and integer? odd?))
> (s/def ::a integer?)
> (s/def ::b integer?)
> (s/def ::c integer?)
> (def s (s/cat :forty-two #{42}
>   :odds (s/+ ::odd?)
>   :m (s/keys :req-un [::a ::b ::c])
>   :oes (s/* (s/cat :o ::odd? :e ::even?))
>   :ex (s/alt :odd ::odd? :even ::even?)))
> user=> (s/conform s [42 11 13 15 {:a 1 :b 2 :c 3} 1 2 3 42 43 44 11])
> {:forty-two 42,
>  :odds [11 13 15],
>  :m {:a 1, :b 2, :c 3},
>  :oes [{:o 1, :e 2} {:o 3, :e 42} {:o 43, :e 44}],
>  :ex {:odd 11}}
>
>
> in http://clojure.org/about/spec
>
>
> On Mon, May 23, 2016 at 5:12 PM, Rich Hickey  wrote:
>
>> Introducing clojure.spec
>>
>> I'm happy to introduce today clojure.spec, a new core library and support 
>> for data and function specifications in Clojure.
>>
>> Better communication
>>
>> Clojure is a dynamic language, and thus far we have relied on 
>> documentation or external libraries to explain the use and behavior of 
>> functions and libraries. But documentation is difficult to produce, is 
>> frequently not maintained, cannot be automatically checked and varies 
>> greatly in quality. Specs are expressive and precise. Including spec in 
>> Clojure creates a lingua franca with which we can state how our programs 
>> work and how to use them.
>>
>> More leverage and power
>>
>> A key advantage of specifications over documentation is the leverage they 
>> provide. In particular, specs can be utilized by programs in ways that docs 
>> cannot. Defining specs takes effort, and spec aims to maximize the return 
>> you get from making that effort. spec gives you tools for leveraging specs 
>> in documentation, validation, error reporting, destructuring, 
>> instrumentation, test-data generation and generative testing.
>>
>> Improved developer experience
>>
>> Error messages from macros are a perennial challenge for new (and 
>> experienced) users of Clojure. specs can be used to conform data in macros 
>> instead of using a custom parser. And Clojure's macro expansion will 
>> automatically use specs, when present, to explain errors to users. This 
>> should result in a greatly improved experience for users when errors occur.
>>
>> More robust software
>>
>> Clojure has always been about simplifying the development of robust 
>> software. In all languages, dynamic or not, tests are essential to quality 
>> - too many critical properties are not captured by common type systems. 
>> spec has been designed from the ground up to directly support generative 
>> testing via test.check https://github.com/clojure/test.check. When you 
>> use spec you get generative tests for free.
>>
>> Taken together, I think the features of spec demonstrate the ongoing 
>> advantages of a powerful dynamic language like Clojure for building robust 
>> software - superior expressivity, instrumentation-enhanced REPL-driven 
>> development, sophisticated testing and more flexible systems. I encourage 
>> you to read the spec rationale and overview  
>> http://clojure.org/about/spec. Look for spec's inclusion in the next 
>> alpha release of Clojure, within a day or so.
>>
>> Note that spec is still alpha, and some details are likely to change. 
>> Feedback welcome.
>>
>> I hope you find spec useful and powerful!
>>
>> Rich
>>
>> --
>> 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.
>>
>
>
>
> -- 
> Kind Regards,
> Atamert Ölçgen
>
> ◻◼◻
> ◻◻◼
> ◼◼◼
>
> www.muhuk.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 

[ANN] Chestnut 0.12.0

[Arne Brasseur]

Chestnut is a Leiningen template for web apps that aims to be super 
beginner friendly. It comes with Figwheel and Om (default) or Reagent. 

The generated README contains elaborate instructions to get you up to speed.

-

This release comes with 

- upgrades to dependencies (ClojureScript, Figwheel, Om, Environ, 
lein-cljsbuild, ...)
- a fix for `lein jar` contributed by Mark Ingram : 
https://github.com/plexus/chestnut/pull/170
- an upgraded README in generated projects, in particular the instructions 
for Emacs/CIDER have been brought up-to-date, and a few remaining 
references to Weasel were removed.

Full Changelog: https://github.com/plexus/chestnut#changelog

Doing a `lein new chestnut` should pull the latest version immediately from 
Clojars (you can check at the bottom of the generated README.)


*Upgrading:*

For existing projects it is recommended to use `lein ancient` to check for 
outdated dependencies, and to apply the change in PR#170 
(https://github.com/plexus/chestnut/pull/170) manually. Note that `lein 
ancient` does not check Leiningen plugins in use, you have to check these 
manually against the latest version on Clojars.

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

[Atamert Ölçgen]

Isn't s redefined in this example:

user=> (require '[clojure.spec :as s])
(s/def ::even? (s/and integer? even?))
(s/def ::odd? (s/and integer? odd?))
(s/def ::a integer?)
(s/def ::b integer?)
(s/def ::c integer?)
(def s (s/cat :forty-two #{42}
  :odds (s/+ ::odd?)
  :m (s/keys :req-un [::a ::b ::c])
  :oes (s/* (s/cat :o ::odd? :e ::even?))
  :ex (s/alt :odd ::odd? :even ::even?)))
user=> (s/conform s [42 11 13 15 {:a 1 :b 2 :c 3} 1 2 3 42 43 44 11])
{:forty-two 42,
 :odds [11 13 15],
 :m {:a 1, :b 2, :c 3},
 :oes [{:o 1, :e 2} {:o 3, :e 42} {:o 43, :e 44}],
 :ex {:odd 11}}


in http://clojure.org/about/spec


On Mon, May 23, 2016 at 5:12 PM, Rich Hickey  wrote:

> Introducing clojure.spec
>
> I'm happy to introduce today clojure.spec, a new core library and support
> for data and function specifications in Clojure.
>
> Better communication
>
> Clojure is a dynamic language, and thus far we have relied on
> documentation or external libraries to explain the use and behavior of
> functions and libraries. But documentation is difficult to produce, is
> frequently not maintained, cannot be automatically checked and varies
> greatly in quality. Specs are expressive and precise. Including spec in
> Clojure creates a lingua franca with which we can state how our programs
> work and how to use them.
>
> More leverage and power
>
> A key advantage of specifications over documentation is the leverage they
> provide. In particular, specs can be utilized by programs in ways that docs
> cannot. Defining specs takes effort, and spec aims to maximize the return
> you get from making that effort. spec gives you tools for leveraging specs
> in documentation, validation, error reporting, destructuring,
> instrumentation, test-data generation and generative testing.
>
> Improved developer experience
>
> Error messages from macros are a perennial challenge for new (and
> experienced) users of Clojure. specs can be used to conform data in macros
> instead of using a custom parser. And Clojure's macro expansion will
> automatically use specs, when present, to explain errors to users. This
> should result in a greatly improved experience for users when errors occur.
>
> More robust software
>
> Clojure has always been about simplifying the development of robust
> software. In all languages, dynamic or not, tests are essential to quality
> - too many critical properties are not captured by common type systems.
> spec has been designed from the ground up to directly support generative
> testing via test.check https://github.com/clojure/test.check. When you
> use spec you get generative tests for free.
>
> Taken together, I think the features of spec demonstrate the ongoing
> advantages of a powerful dynamic language like Clojure for building robust
> software - superior expressivity, instrumentation-enhanced REPL-driven
> development, sophisticated testing and more flexible systems. I encourage
> you to read the spec rationale and overview  http://clojure.org/about/spec.
> Look for spec's inclusion in the next alpha release of Clojure, within a
> day or so.
>
> Note that spec is still alpha, and some details are likely to change.
> Feedback welcome.
>
> I hope you find spec useful and powerful!
>
> Rich
>
> --
> 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.
>



-- 
Kind Regards,
Atamert Ölçgen

◻◼◻
◻◻◼
◼◼◼

www.muhuk.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: clojure.spec

[sean]

OK, that explains a lot. Thank you. That needs to be clarified on the web page 
I think…

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org

From: Alex Miller

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