Re: clojure.spec

[Alex Miller]

On Tuesday, May 24, 2016 at 12:16:32 AM UTC-5, Sean Corfield wrote:
>
> I was a bit puzzled by the :req-un / :opt-un stuff in maps. Am I right 
> that there is a requirement here for the keys to be namespaced but the 
> actual namespace is completely irrelevant / ignored?
>

No - the :req-un / :opt-un keys are used for two purposes:
1. The namespaced key is used to locate the spec in the registry
2. The unnamespaced key is used to find the value in the map

Once those are found, the spec is used to validate the attribute value.

 

>  
>
> (defn thing [m]
>
>   (+ (:a m) (:b m) (or (:c m) 1)))
>
> (s/fdef thing
>
> :args (s/cat :map (s/and (s/keys :req-un [:x/a :y/b]
>
>  :opt-un [:z/c])
>
>  (s/map-of keyword? number?)))
>
> :ret  number?)
>
>  
>
> I tried several namespace prefixes here and it seemed I can use anything 
> and they don’t even need to be consistent.
>

Right - if no spec is found then nothing happens. But if you registered a 
spec as :x/a  or :y/b those specs would be used to validate the arg.

 
>
> Wouldn’t it be easier to just allow un-namespaced keywords here? Or is 
> there some aspect of the namespacing here that I’m missing?
>
>  
>
> Sean Corfield -- (904) 302-SEAN
> An Architect's View -- http://corfield.org
>
>  
>
> *From: *Rich Hickey 
> *Sent: *Monday, May 23, 2016 7:12 AM
> *To: *clojure@googlegroups.com
> *Subject: *clojure.spec
>
>  
>
> 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.
>
>  
>

-- 
You received this message because you are subscribed 

RE: clojure.spec

[sean]

I was a bit puzzled by the :req-un / :opt-un stuff in maps. Am I right that 
there is a requirement here for the keys to be namespaced but the actual 
namespace is completely irrelevant / ignored?

(defn thing [m]
  (+ (:a m) (:b m) (or (:c m) 1)))
(s/fdef thing
:args (s/cat :map (s/and (s/keys :req-un [:x/a :y/b]
 :opt-un [:z/c])
 (s/map-of keyword? number?)))
:ret  number?)

I tried several namespace prefixes here and it seemed I can use anything and 
they don’t even need to be consistent.

Wouldn’t it be easier to just allow un-namespaced keywords here? Or is there 
some aspect of the namespacing here that I’m missing?

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

From: Rich Hickey

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

[Alex Miller]

Hi Leif, thanks for the feedback!

The use for regex ops is primarily expected to be syntax where greedy is 
typically a fine default (and where the sequence length is typically not 
long with exact quantification).

You can use the & operator though to add arbitrary predicates around 
another regex operator:

;; i1 is greedy here
(def nn (s/cat :i1 (s/+ integer?) :i2 (s/+ integer?)))
(s/conform nn [1 2 3 4 5])
=> {:i1 [1 2 3 4], :i2 [5]}

;; use s/& to bound i1 to length < 3
(def nn' (s/cat :i1 (s/& (s/+ integer?) #(< (count %) 3)) :i2 (s/+ 
integer?)))
(s/conform nn' [1 2 3 4 5])
=> {:i1 [1 2], :i2 [3 4 5]}

that predicate is arbitrary so could set any occurence operator needed 
there. In practice I have been using spec every day for weeks and I have 
only occasionally needed anything like this though.

Re the test.check dependency - this will be made more explicit in docs to 
come. But fair point.

I have written a lengthy guide with more examples which we'll release 
tomorrow. The rationale was not meant to serve as either tutorial docs or 
reference material but rather as ... the rationale. :)

On namespaced keywords, there are a couple language changes also on the way 
to provide namespaced literal maps (for reading and printing) and 
namespaced key destructuring. I expect these will also help in reducing the 
typing burden of namespaced keys.  See CLJ-1910 
 and CLJ-1919 
. It's likely these will be 
included in alpha2.


On Monday, May 23, 2016 at 10:42:27 PM UTC-5, Leif wrote:
>
> Feedback:
>
> The regex quantifiers seem to be greedy.  I suppose that is the standard 
> choice, but it would be nice if the docs explicitly said that.
>
> Maybe have a 'rep' macro for exact quantification?  My use cases for this 
> are short sequences that would be handled just fine by 'cat', so I don't 
> really need it.  But if someone else needs to specify long-ish but 
> fixed-size sequences, or sequences with a specific length range, they 
> should speak up now.
>
> The docs should mention that you need to provide your own test.check 
> dependency.  They do obliquely, but being explicit never hurts.
>
> An example or two under the "Features > Overview > Maps" section would be 
> nice.  The text makes many good points about the design decisions made for 
> map specs, I'd like to see them in action.  (I am skeptical that a short 
> example would convince me to namespace all my damn map keywords, though 
> perhaps you'll lead me down the virtuous path.)
>
> All that said, it looks good and I think I'll have fun trying it out.
> --Leif
>
> On Monday, May 23, 2016 at 10:12:29 AM UTC-4, 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 
>> 

Re: clojure.spec

[Leif]

Feedback:

The regex quantifiers seem to be greedy.  I suppose that is the standard 
choice, but it would be nice if the docs explicitly said that.

Maybe have a 'rep' macro for exact quantification?  My use cases for this 
are short sequences that would be handled just fine by 'cat', so I don't 
really need it.  But if someone else needs to specify long-ish but 
fixed-size sequences, or sequences with a specific length range, they 
should speak up now.

The docs should mention that you need to provide your own test.check 
dependency.  They do obliquely, but being explicit never hurts.

An example or two under the "Features > Overview > Maps" section would be 
nice.  The text makes many good points about the design decisions made for 
map specs, I'd like to see them in action.  (I am skeptical that a short 
example would convince me to namespace all my damn map keywords, though 
perhaps you'll lead me down the virtuous path.)

All that said, it looks good and I think I'll have fun trying it out.
--Leif

On Monday, May 23, 2016 at 10:12:29 AM UTC-4, 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: new learner question

[Phil Virgo]

Don't want to thank each of you individually - so to all who answered  - 
Thank-you!

On Monday, May 23, 2016 at 9:10:47 PM UTC-4, Phil Virgo wrote:
>
> I just starting to try and teach myself Clojure.  Kindly let me know if 
> there is a more appropriate place I should post simple questions.
>
>
> (def s '(1 1 1 4 99) 
>
> (take-while  #(= (first s) %) s)  ; works fine: (1 1 1)
>
> (take-while  #(= (first %) %) s)  ; IllegalArgumentException Don't know 
> how to create ISeq from: java.lang.Long  clojure.lang.RT.seqFrom 
> (RT.java:505)
>
> It appears as though "%" cannot be used within a nested function - but 
> this works 
>
> (#(prn (+ 3 %) % ) 5) ; works fine:  8 5
>
> Does anyone know what is the rule of statement construction being violated?
>
> ~thanks
>

-- 
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: new learner question

[JvJ]

>
>
>
> Nope, that's fine. (Although you can't nest one anonymous function inside 
> another as then it would be ambiguous what % refers to.)
>

To further clarify when anonymous functions can't be nested:

#(+ % (+ % (+ % (+ % ==> totally legal 

#(+ % (#(* 2 %) %)) ===> totally not legal

In the first example, % is always the same.  However, in the second 
example, the #() form tries to introduce a *new* function, which can't be 
nested with this syntax.

However.
#(+ % ((fn [x] (* 2 x)) %)) ===> totally fine.  You can nest as many 
functions as you want if you write them as (fn [] ...)

-- 
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: new learner question

[Alex Miller]

On Monday, May 23, 2016 at 8:10:47 PM UTC-5, Phil Virgo wrote:
>
> I just starting to try and teach myself Clojure.  Kindly let me know if 
> there is a more appropriate place I should post simple questions.
>

This is fine! You might also enjoy the #beginners room on the 
http://clojurians.net/ Slack for live chat. 

>
>
> (def s '(1 1 1 4 99) 
>
> (take-while  #(= (first s) %) s)  ; works fine: (1 1 1)
>
> (take-while  #(= (first %) %) s)  ; IllegalArgumentException Don't know 
> how to create ISeq from: java.lang.Long  clojure.lang.RT.seqFrom 
> (RT.java:505)
>

The anon function here is being invoked on the first value, which is 1 so 
that function becomes:

#(= (first 1) 1)

And the error is that (first 1) is being passed a number rather than 
something seqable. 
 

>
> It appears as though "%" cannot be used within a nested function
>

Nope, that's fine. (Although you can't nest one anonymous function inside 
another as then it would be ambiguous what % refers to.)
 

> - but this works 
>
> (#(prn (+ 3 %) % ) 5) ; works fine:  8 5
>

here this turns into:

#(prn (+ 3 5) 5) 

which is fine.

Hope that helps!
 

>
> Does anyone know what is the rule of statement construction being violated?
>
> ~thanks
>

-- 
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: new learner question

[JvJ]

Your use of % is syntactically correct.

However, think of what is happening in the second example.

Every time take-while invokes your function #(= (first %) %), % is bound to 
an element of the list s.

So, something like this would happen when take-while is checking the first 
element: (= (first 1) 1).

The exception just means that the function "first" can only work on 
sequences.  Numbers are not sequences.


On Monday, 23 May 2016 18:10:47 UTC-7, Phil Virgo wrote:
>
> I just starting to try and teach myself Clojure.  Kindly let me know if 
> there is a more appropriate place I should post simple questions.
>
>
> (def s '(1 1 1 4 99) 
>
> (take-while  #(= (first s) %) s)  ; works fine: (1 1 1)
>
> (take-while  #(= (first %) %) s)  ; IllegalArgumentException Don't know 
> how to create ISeq from: java.lang.Long  clojure.lang.RT.seqFrom 
> (RT.java:505)
>
> It appears as though "%" cannot be used within a nested function - but 
> this works 
>
> (#(prn (+ 3 %) % ) 5) ; works fine:  8 5
>
> Does anyone know what is the rule of statement construction being violated?
>
> ~thanks
>

-- 
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: new learner question

[Dan Girellini]

On May 23, 2016 at 6:10:46 PM, Phil Virgo (pwvi...@gmail.com) wrote:

(take-while  #(= (first %) %) s)  ; IllegalArgumentException Don't know how
to create ISeq from: java.lang.Long  clojure.lang.RT.seqFrom (RT.java:505)


Your problem is that take-while will call the predicate for each item in
the collection ’s’. So you’re calling first on each item in s and you can’t
call first on a number. Thus the error you got.


—dan.

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

new learner question

[Phil Virgo]

I just starting to try and teach myself Clojure.  Kindly let me know if 
there is a more appropriate place I should post simple questions.


(def s '(1 1 1 4 99) 

(take-while  #(= (first s) %) s)  ; works fine: (1 1 1)

(take-while  #(= (first %) %) s)  ; IllegalArgumentException Don't know how 
to create ISeq from: java.lang.Long  clojure.lang.RT.seqFrom (RT.java:505)

It appears as though "%" cannot be used within a nested function - but this 
works 

(#(prn (+ 3 %) % ) 5) ; works fine:  8 5

Does anyone know what is the rule of statement construction being violated?

~thanks

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

clojure.spec

[Alan Moore]

Your timing couldn't have been better... we have been needing something like 
this. Thought of building something similar which would only have been an ad 
hoc, informally specified, bug ridden, slow implementation of half of 
clojure.spec.

Thank you for spending you hammock time on this important feature/library. 
Looking forward to using it.

Alan

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

On 5/23/16, 3:45 PM, "Rich Hickey"  wrote:
>That one’s already fixed if you grab the latest.

Confirmed! Thank you!

Sean



-- 
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] trapperkeeper 1.4.1

[Joe Pinsonault]

Today we released puppetlabs/trapperkeeper v1.4.1 to clojars.

There is a single bugfix in this release: TK-375 
.

TK-375 resolves startup issues for users that use a bootstrap.cfg inside 
their project's jar file. 

For more info see the CHANGELOG and docs

CHANGELOG: https://github.com/puppetlabs/trapperkeeper
/blob/master/CHANGELOG.md#140
Trapperkeeper github wiki: https://github.com/puppetlabs/trapperkeeper/wiki

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

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

[Rich Hickey]

That one’s already fixed if you grab the latest.

> On May 23, 2016, at 6:37 PM, Sean Corfield  wrote:
> 
> On 5/23/16, 2:29 PM, "Rich Hickey"  richhic...@gmail.com> 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.
> 
> Nice:
> 
>  (require '[clojure.spec :as s])
>  (s/fdef clojure.core/symbol
>:args (s/alt :separate (s/cat :ns string? :n string?)
> :str string?
> :sym symbol?)
>:ret symbol?)
> 
>  (doc symbol)
>  -
>  clojure.core/symbol
>  ([name] [ns name])
>Returns a Symbol with the given namespace and name.
>  Spec
>args: (alt :separate (cat :ns string? :n string?) :str string? :sym 
> symbol?)
>ret: symbol?
> 
> Looks like a small bug in explain tho’ – is it worth filing a JIRA bug yet or 
> wait until the Alpha?
> 
>  (s/instrument-all)
> 
>  (symbol 1) ;; this is fine…
> 
>  clojure.lang.ExceptionInfo: Call to #'clojure.core/symbol did not conform to 
> spec:
>  At: [:args :separate :ns] val: 1 fails 
> predicate: string?
>  At: [:args :str] val: 1 fails predicate: string?
>  At: [:args :sym] val: 1 fails predicate: symbol?
>  :clojure.spec/args  (1)
> 
>  (symbol "a" :a) ;; this should explain that :a fails predicate: string?
> 
> java.lang.IllegalArgumentException: No matching clause: :clojure.spec/accept
>   clojure.spec/op-explain/invokeStatic  spec.clj: 
> 1196
> clojure.spec/op-explain/fn  spec.clj: 
> 1192
>clojure.core/map/fn  core.clj: 
> 2657
>...
> 
>clojure.core/apply/invokeStatic  core.clj: 
>  646
>   clojure.spec/op-explain/invokeStatic  spec.clj: 
> 1196
>   clojure.spec/re-explain/invokeStatic  spec.clj: 
> 1259
> clojure.spec/regex-spec-impl/reify/explain*  
> spec.clj: 1282
>clojure.spec/explain-data*/invokeStatic  spec.clj: 
>  143
> clojure.spec/spec-checking-fn/conform!  spec.clj: 
>  520
>   clojure.spec/spec-checking-fn/fn  spec.clj: 
>  532
> 
> 
> 
> 
> -- 
> 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

[George Singer]

Rich Hickey  gmail.com> writes:

> 
> I did most of the design of spec in a (paper) notebook.
> 
> The rationale tries to capture the salient driving forces.
> 
> If there is a specific question you have I’d be happy to answer.
> 
> Rich
> 
> > On May 23, 2016, at 4:11 PM, Ivan Reese  gmail.com> 
wrote:
> > 
> > Is there anywhere we can read anything about the design process behind 
clojure.spec? I took a look at
> dev.clojure.org / JIRA, but I haven't yet found anything on the topic.
> > 
> > -- 
> > 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+unsubscribe  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+unsubscribe  googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> 

I'd love to hear Rich give a talk about this (the design process, his 
rationale, and so forth) -- especially how it relates to static type 
systems. I know that there's write-up already on the clojure website, but 
this would be a great talk also.

Can't wait to use this.

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

Re: clojure.spec

[Sean Corfield]

On 5/23/16, 2: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.

Nice:

  (require '[clojure.spec :as s])
  (s/fdef clojure.core/symbol
:args (s/alt :separate (s/cat :ns string? :n string?)
 :str string?
 :sym symbol?)
:ret symbol?)

  (doc symbol)
  -
  clojure.core/symbol
  ([name] [ns name])
Returns a Symbol with the given namespace and name.
  Spec
args: (alt :separate (cat :ns string? :n string?) :str string? :sym symbol?)
ret: symbol?

Looks like a small bug in explain tho’ – is it worth filing a JIRA bug yet or 
wait until the Alpha?

  (s/instrument-all)

  (symbol 1) ;; this is fine…

  clojure.lang.ExceptionInfo: Call to #'clojure.core/symbol did not conform to 
spec:
  At: [:args :separate :ns] val: 1 fails predicate: 
string?
  At: [:args :str] val: 1 fails predicate: string?
  At: [:args :sym] val: 1 fails predicate: symbol?
  :clojure.spec/args  (1)

  (symbol "a" :a) ;; this should explain that :a fails predicate: string?

java.lang.IllegalArgumentException: No matching clause: :clojure.spec/accept
   clojure.spec/op-explain/invokeStatic  spec.clj: 
1196
 clojure.spec/op-explain/fn  spec.clj: 
1192
clojure.core/map/fn  core.clj: 
2657
... 
   
clojure.core/apply/invokeStatic  core.clj:  
646
   clojure.spec/op-explain/invokeStatic  spec.clj: 
1196
   clojure.spec/re-explain/invokeStatic  spec.clj: 
1259
clojure.spec/regex-spec-impl/reify/explain*  spec.clj: 
1282
clojure.spec/explain-data*/invokeStatic  spec.clj:  
143
 clojure.spec/spec-checking-fn/conform!  spec.clj:  
520
   clojure.spec/spec-checking-fn/fn  spec.clj:  
532




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

[Shaun Parker]

Thanks to everyone who worked on it! I'm excited there's finally an 
idiomatic way and can't wait to use it.

Is there any chance the three clojure.spec namespaces will be released as a 
library that could be use until 1.9.0 is released? It seems like we'd only 
be missing compile time macro checking/reporting and the updated 
clojure.repl/doc unless I'm missing something. It'd be nice to start 
gradually using everything else now.

On Monday, May 23, 2016 at 3:20:36 PM UTC-6, Rich Hickey wrote:
>
> I did most of the design of spec in a (paper) notebook. 
>
> The rationale tries to capture the salient driving forces. 
>
> If there is a specific question you have I’d be happy to answer. 
>
> Rich 
>
> > On May 23, 2016, at 4:11 PM, Ivan Reese  
> wrote: 
> > 
> > Is there anywhere we can read anything about the design process behind 
> clojure.spec? I took a look at dev.clojure.org / JIRA, but I haven't yet 
> found anything on the topic. 
> > 
> > -- 
> > 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]

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

Re: clojure.spec

[Nicola Mometto]

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 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.
>> 
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this 

Re: clojure.spec

[Nicola Mometto]

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

Re: clojure.spec

[Ambrose Bonnaire-Sergeant]

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

Re: clojure.spec

[Ambrose Bonnaire-Sergeant]

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

Re: clojure.spec

[Rich Hickey]

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

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

[Alex Miller]

You can dynamically install defmethods at runtime too so you could catch 
this problem when it falls into the default, generate the schema, register 
it, then re-invoke. Theoretically.


On Monday, May 23, 2016 at 4:20:38 PM UTC-5, 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.
>

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

[Andrey Grin]

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

I did most of the design of spec in a (paper) notebook.

The rationale tries to capture the salient driving forces.

If there is a specific question you have I’d be happy to answer.

Rich

> On May 23, 2016, at 4:11 PM, Ivan Reese  wrote:
> 
> Is there anywhere we can read anything about the design process behind 
> clojure.spec? I took a look at dev.clojure.org / JIRA, but I haven't yet 
> found anything on the topic.
> 
> -- 
> 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

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

[Alex Miller]

clojure.spec has been developed internally for the last couple months. It 
combines a lot of different threads of thought. What are looking for?

There will be some more usage docs coming soon.

On Monday, May 23, 2016 at 3:11:30 PM UTC-5, Ivan Reese wrote:
>
> Is there anywhere we can read anything about the design process behind 
> clojure.spec? I took a look at dev.clojure.org / JIRA, but I haven't yet 
> found anything on the topic.
>

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

[Ivan Reese]

Is there anywhere we can read anything about the design process behind 
clojure.spec? I took a look at dev.clojure.org / JIRA, but I haven't yet 
found anything on the topic.

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

[Andrey Grin]

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.


Am Montag, 23. Mai 2016 21:41:01 UTC+2 schrieb Alex Miller:
>
> That schema looks weird to me as it seems to under-constrain leaf vs 
> branch so this is not really equivalent but makes sense to me:
>
> (spec/def ::tree (spec/or :leaf ::leaf :branch ::branch))
> (spec/def ::leaf integer?)
> (spec/def ::branch (spec/cat :left ::tree :right ::tree))
> (spec/conform ::tree [[1 2] [3 4]])
> => [:branch {:left [:branch {:left [:leaf 1], :right [:leaf 2]}], :right 
> [:branch {:left [:leaf 3], :right [:leaf 4]}]}]
>
> Because you register specs in the registry by keyword that gives you the 
> point of indirection to do recursive structures.
>
> Generate some trees!
>
> (gen/sample (spec/gen ::tree) 5)
> => (-1 -1 (0 0) (0 2) (-1 -1))
>
> (gen/sample (spec/gen ::tree) 5)
> => (((-1 0) 0) 0 1 (0 1) (1 -3))
>
>
> On Monday, May 23, 2016 at 11:16:44 AM UTC-5, Alex Miller wrote:
>>
>> Yes, you can create recursive definitions by registering a spec that 
>> refers to itself via registered name (a namespaced keyword).
>>
>>
>> On Monday, May 23, 2016 at 11:13:24 AM UTC-5, Andrey Grin wrote:
>>>
>>>  Is it planned to support recursive definitions? Example from.plumatic 
>>> schema:
>>>  
>>>
>>> (def BinaryTree 
>>>   (maybe ;; any empty binary tree is represented by nil
>>>{:value long 
>>> :left (recursive #'BinaryTree) 
>>> :right (recursive #'BinaryTree)}))
>>>
>>>

-- 
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] Neanderthal 0.6.0: new support for AMD, Nvidia, and Intel GPUs on Linux, Windows and OS X (fast matrix library)

[Dragan Djuric]

This is a major release of Neanderthal, a fast native & GPU matrix library:

In this release, spotlight is on the new GPU engine, that:

* Works on all three major hardware platforms: AMD, Nvidia, and Intel
* Works on all three major operating systems: Linux, Windows, and OS X
* Is even faster, so it is now more than 1000x faster than the optimized 
Java libraries for 8192x8192 matrix multiplication.

Version 0.6.0 is in clojars
Documentation and the tutorials can be found at the usual place: 
http://neanderthal.uncomplicate.org

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

Awesome, thanks!  I had misunderstood where the idea of a sequence was 
created (the sequential context as you put it).

On Monday, May 23, 2016 at 12:28:32 PM UTC-7, Alex Miller wrote:
>
> Yeah, nested regexes are one of the places people are most likely to be 
> tripped up. 
>
> One of those inner lists could be speced as:
>
> (def string-list (s/* string?)) 
>
> ;; or as (s/coll-of string?) - not a strong preference in this particular 
> case but there are tradeoffs
>
> And then the outer list is something like this:
>
> (def outer (s/* (s/spec string-list))
>
> where the s/spec is the key thing - that creates a new "sequential 
> context". Otherwise, the string-list regex ops become part of the outer 
> regex ops.
>
> One difference here will be that the spec above will conform the 
> string-list to a vector (as all sequential things conform to a vector). The 
> coll-of approach would give you control over that though:
>
> (s/conform (s/* (s/coll-of string? ())) ['("a" "b" "c") '("d" "e" "f")])
> => [("a" "b" "c") ("d" "e" "f")]
>
> The benefit of using s/* in string-list is that if you wanted to include 
> string-list inside another regex you could but with coll-of, it would 
> always start a new collection:
>
> (s/conform (s/cat :num integer? :strs string-list) [100 "a" "b"])
> => {:num 100, :strs ["a" "b"]}
>
> So, tradeoffs.
>
> On Monday, May 23, 2016 at 2:08:49 PM UTC-5, scott stackelhouse wrote:
>>
>> Could someone describe what a spec of a seq in a seq would look like? 
>>  i.e. ['("a" "b" "c") '("d" "e" "f")].  I'm not quite "getting it."
>>
>> --Scott
>>
>> On Monday, May 23, 2016 at 7:12:29 AM 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 

Re: clojure.spec

[Alex Miller]

That schema looks weird to me as it seems to under-constrain leaf vs branch 
so this is not really equivalent but makes sense to me:

(spec/def ::tree (spec/or :leaf ::leaf :branch ::branch))
(spec/def ::leaf integer?)
(spec/def ::branch (spec/cat :left ::tree :right ::tree))
(spec/conform ::tree [[1 2] [3 4]])
=> [:branch {:left [:branch {:left [:leaf 1], :right [:leaf 2]}], :right 
[:branch {:left [:leaf 3], :right [:leaf 4]}]}]

Because you register specs in the registry by keyword that gives you the 
point of indirection to do recursive structures.

Generate some trees!

(gen/sample (spec/gen ::tree) 5)
=> (-1 -1 (0 0) (0 2) (-1 -1))

(gen/sample (spec/gen ::tree) 5)
=> (((-1 0) 0) 0 1 (0 1) (1 -3))


On Monday, May 23, 2016 at 11:16:44 AM UTC-5, Alex Miller wrote:
>
> Yes, you can create recursive definitions by registering a spec that 
> refers to itself via registered name (a namespaced keyword).
>
>
> On Monday, May 23, 2016 at 11:13:24 AM UTC-5, Andrey Grin wrote:
>>
>>  Is it planned to support recursive definitions? Example from.plumatic 
>> schema:
>>  
>>
>> (def BinaryTree 
>>   (maybe ;; any empty binary tree is represented by nil
>>{:value long 
>> :left (recursive #'BinaryTree) 
>> :right (recursive #'BinaryTree)}))
>>
>>

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

[Alex Miller]

Yeah, nested regexes are one of the places people are most likely to be 
tripped up. 

One of those inner lists could be speced as:

(def string-list (s/* string?)) 

;; or as (s/coll-of string?) - not a strong preference in this particular 
case but there are tradeoffs

And then the outer list is something like this:

(def outer (s/* (s/spec string-list))

where the s/spec is the key thing - that creates a new "sequential 
context". Otherwise, the string-list regex ops become part of the outer 
regex ops.

One difference here will be that the spec above will conform the 
string-list to a vector (as all sequential things conform to a vector). The 
coll-of approach would give you control over that though:

(s/conform (s/* (s/coll-of string? ())) ['("a" "b" "c") '("d" "e" "f")])
=> [("a" "b" "c") ("d" "e" "f")]

The benefit of using s/* in string-list is that if you wanted to include 
string-list inside another regex you could but with coll-of, it would 
always start a new collection:

(s/conform (s/cat :num integer? :strs string-list) [100 "a" "b"])
=> {:num 100, :strs ["a" "b"]}

So, tradeoffs.

On Monday, May 23, 2016 at 2:08:49 PM UTC-5, scott stackelhouse wrote:
>
> Could someone describe what a spec of a seq in a seq would look like? 
>  i.e. ['("a" "b" "c") '("d" "e" "f")].  I'm not quite "getting it."
>
> --Scott
>
> On Monday, May 23, 2016 at 7:12:29 AM 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: clojure.spec

[scott stackelhouse]

Could someone describe what a spec of a seq in a seq would look like?  i.e. 
['("a" "b" "c") '("d" "e" "f")].  I'm not quite "getting it."

--Scott

On Monday, May 23, 2016 at 7:12:29 AM 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: clojure.spec

[Nicola Mometto]

Some minor feedback while reading through `clojure.spec`:

`clojure.spec/->sym`  has been implemented in a significant number of libraries 
already (see: https://crossclj.info/clojure/var->sym.html), I propose we 
include this in `clojure.core` under the name of `var->sym`



> On 23 May 2016, at 15:12, 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.

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


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: clojure.spec

[Sean Corfield]

Awesome! I know one company that’s going to jump straight on 1.9.0-alpha1! ☺

Heck, we may even start today with 1.9.0-master-SNAPSHOT since clojure.spec was 
committed a couple of hours ago ☺

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/23/16, 7:12 AM, "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.


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

[Alex Miller]

Yes, you can create recursive definitions by registering a spec that refers 
to itself via registered name (a namespaced keyword).


On Monday, May 23, 2016 at 11:13:24 AM UTC-5, Andrey Grin wrote:
>
>  Is it planned to support recursive definitions? Example from.plumatic 
> schema:
>  
>
> (def BinaryTree 
>   (maybe ;; any empty binary tree is represented by nil
>{:value long 
> :left (recursive #'BinaryTree) 
> :right (recursive #'BinaryTree)}))
>
>

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

[Andrey Grin]

 Is it planned to support recursive definitions? Example from.plumatic 
schema:
 

(def BinaryTree 
  (maybe ;; any empty binary tree is represented by nil
   {:value long 
:left (recursive #'BinaryTree) 
:right (recursive #'BinaryTree)}))

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

[Alan Thompson]

Looks great - eagerly awaiting a chance to use it.
Alan


On Mon, May 23, 2016 at 7:48 AM,  wrote:

> This looks incredible and it sounds like something which could immediately
> be put to good use in both hobby and production projects. Excited to test
> it out when the alpha is available. Thank you!
>
>
> On Monday, May 23, 2016 at 10:12:29 AM UTC-4, 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.
>

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

[adrian . medina]

This looks incredible and it sounds like something which could immediately 
be put to good use in both hobby and production projects. Excited to test 
it out when the alpha is available. Thank you!

On Monday, May 23, 2016 at 10:12:29 AM UTC-4, 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.

[ANN] Lambda Island, weekly ClojureScript/Clojure screencast

[Arne Brasseur]

Hi Everyone,

Last week I launched Lambda Island [1], a subscription based screencast 
series about web development with Clojure and ClojureScript.

So far there are four episodes on-line, including one freebie. All episodes 
come with a full transcript and code samples.

I will cover both front-end with React and Reagent, and back-end, where I'm 
starting with Luminus as a foundation. The last episode was about 
ClojureScript/JavaScript interop, which will serve as a basis for talking 
about React, before moving on to Reagent and Re-frame in later episodes. 

Subscriptions are US$ 12 per month, with discounts for quarterly/annually. 

If you're a student, unemployed, a ClojureBridge alumni, or are for any 
reason financially in a tight spot, you can use this coupon code [2] to get 
33% off indefinitely.

I would greatly appreciate your support. My inbox is open if you have any 
feedback.

[1] https://lambdaisland.com/
[2] https://lambdaisland.com/coupon/STUDENT

Thanks,
Arne

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

clojure.spec

[Rich Hickey]

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: can clojure have es7 async await

[Xiangtao Zhou]

hi Andrey, 

I think,  javascript basically designed with event mechnism, especially IO 
api. The async/await api is cps transform with promise.  async makes the 
function return promise, await make cps transform. in clojure, these may 
associate with core.async, I mean use channel replace promise.

On Monday, May 23, 2016 at 9:14:22 PM UTC+8, Andrey Antukh wrote:
>
> I'm not pretty sure if this answers your question,  but I have similar 
> async/await syntax already implemented in promesa library: 
> http://funcool.github.io/promesa/latest/#async-await-syntax
>
> Regards.
> Andrey
>
> On Mon, May 23, 2016 at 4:07 PM, Xiangtao Zhou  > wrote:
>
>> hi Everyone, 
>>
>> es7 async/await makes javascript easily understandable,  and avoid the 
>> callback hell. can clojure have one library like this?
>>
>> scala version is here https://github.com/scala/async.
>>
>>
>> Thanks.
>>
>> Joe.
>>
>> -- 
>> 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.
>>
>
>
>
> -- 
> Andrey Antukh - Андрей Антух - 
> http://www.niwi.nz
> https://github.com/niwinz
>

-- 
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: Following type annotations across call sites to eliminate reflection?

[Phillip Lord]

I macro'd this out (macro's with type-hints are surprisingly tricky).

So, you end with this

(with-types [val [String Double Boolean]]
(C/met val)

Which calls C/met with the right thing without reflection (unless you
count "instance?").

The code is in tawny-owl.

https://github.com/phillord/tawny-owl/blob/master/src/tawny/util.clj

Phil

lvh <_...@lvh.io> writes:

> Hi Reid,
>
>
>> On May 21, 2016, at 11:44 PM, Reid McKenzie  wrote:
>> 
>> You should be able to do this:
>> 
>> (defn f [a ^bytes b ^bytes c]
>>(if (instance? ByteBuffer a)
>>  (.f binding ^ByteBuffer a b c)
>>  (.f binding ^bytes a b c)))
>> 
>> 
>> You have a bimorphic function and yes there isn't a way to express that with 
>> Clojure's calling convention and consequent hinting support. So 1) yes, 2) 
>> no but no promises there, 3) see above.
>
> Thanks! That confirms my suspicions. Unfortunately, I was hoping to solve this
> statically. Since some of these call sites are really only useful internally,
> I’ll deal with the multi-var version, because my library’s the only one to pay
> that cost.
>
>
> thanks!
> lvh
>
>> I don't have a Clojure instance handy, but this should compile to
>> 1) load the a argument
>> 2) check instanceof against the class ByteBuffer
>> 3) branch to the appropriate instance invoke
>> 4) load b, c, a, from the arguments (as Objects), checkcasting appropriately
>> to get typed as hinted values on the stack
>> 5) invoke (fully type qualified, no reflection).
>> 
>> On Saturday, May 21, 2016 at 4:57:43 PM UTC-5, lvh ‌ wrote:
>> Hi, 
>> 
>> 
>> 
>> I’m working on caesium[1], Clojure bindings for libsodium using jnr-ffi. Up
>> until recently, I was able to stick to byte arrays for all APIs; but I’ve
>> started writing new nonce-misuse resistant cryptosystems[2], so I need to
>> have some byte-level layout within a byte array. I’m using
>> java.nio.ByteBuffer to provide mutable byte array “views” on top of an
>> existing byte array.
>> 
>> The underlying C API takes (const) char *s. jnr-ffi understands how to
>> translate both byte[] and ByteBuffer to char *. Previously, I had functions
>> like:
>> 
>> (defn f 
>>   [^bytes a ^bytes b ^bytes c] 
>>   (.f binding a b c)) 
>> 
>> All was well; no reflection. However, now `binding` has two signatures for
>> f: [byte[] byte[] byte[]] and [ByteBuffer byte[] byte[]]. If I remove the
>> first ^byte annotation, everything works well, but this generates reflection
>> warnings.
>> 
>> 1. Does this reflection warning mean that there will be actual reflection if
>> the type is known at the call site? (I believe the answer is “yes”.)
>> 2. Does that change with AOT? 
>> 3. Is there a way to keep the same fn name, e.g. have: 
>> 
>> (defn f 
>>   [a ^bytes b ^bytes c] 
>>   (.f binding a b c)) 
>> 
>> … without reflection, as long as all callers of f have the type of `a`
>> statically determined? Again, I’m assuming the answer here is “no”, because
>> this resolution is done locally.
>> 
>> I can solve this in a macro since the two definitions are identical except
>> for the type hint, but I’d first just like to check that I’m not missing
>> some of the finer points of Java interop/type hinting. Also, does this mean
>> that I necessarily have two fns with different names, one for each
>> signature? E.g.:
>> 
>> (defn f-bytes 
>>   [^bytes a ^bytes b ^bytes c] 
>>   (.f binding a b c)) 
>> 
>> (defn f-bytebuffer 
>>   [^java.nio.ByteBuffer a ^bytes b ^bytes c] 
>>   (.f binding a b c)) 
>> 
>> I know that having two overloads with the same arity doesn’t work, so I’m
>> guessing the answer is “no" there as well :-(
>> 
>> 
>> Thanks in advance! 
>> lvh 
>> 
>> [1]: https://github.com/lvh/caesium  
>> [2]: https://www.lvh.io/posts/nonce-misuse-resistance-101.html
>> 
>> 
>> -- 
>> 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
>> .

-- 
Phillip Lord,   Phone: +44 (0) 191 208 7827
Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk
School of Computing Science,

Re: can clojure have es7 async await

[Andrey Antukh]

I'm not pretty sure if this answers your question,  but I have similar
async/await syntax already implemented in promesa library:
http://funcool.github.io/promesa/latest/#async-await-syntax

Regards.
Andrey

On Mon, May 23, 2016 at 4:07 PM, Xiangtao Zhou  wrote:

> hi Everyone,
>
> es7 async/await makes javascript easily understandable,  and avoid the
> callback hell. can clojure have one library like this?
>
> scala version is here https://github.com/scala/async.
>
>
> Thanks.
>
> Joe.
>
> --
> 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.
>



-- 
Andrey Antukh - Андрей Антух - 
http://www.niwi.nz
https://github.com/niwinz

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

can clojure have es7 async await

[Xiangtao Zhou]

hi Everyone, 

es7 async/await makes javascript easily understandable,  and avoid the 
callback hell. can clojure have one library like this?

scala version is here https://github.com/scala/async.


Thanks.

Joe.

-- 
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] New Clojure Podcast: defn

[Terje Dahl]

Loved it.  Very good start.
Looking forwards to your discussion on Reader.



On Thursday, May 19, 2016 at 7:43:44 AM UTC+2, Vijay Kiran wrote:
>
> Hello Everyone,
>
> Just wanted to let you know that we started a new podcast about Clojure: 
> https://defn.audio
>
> We published our first episode and plan to release a new one every two 
> weeks. It is available on iTunes 
> https://itunes.apple.com/podcast/defn/id1114899563 and SoundCloud: 
> https://soundcloud.com/defn-771544745
>
> You can also get the RSS feed via 
> http://feeds.soundcloud.com/users/soundcloud:users:220484243/sounds.rss
>
> We'd appreciate if you can tune in and give us some feedback!
>
> Thanks for listening,
> Vijay & Ray
>

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