Re: any? in clojure 1.9.0 alpha

[Devin Walters]

The more I've thought about it, the more I've resigned myself to the fact that 
any? is the only rational choice. We have `some?`, `some`, `not-any?`, and 
`any?`. There's no resolving the asymmetry without breaking code, and it's 
undeniably true that `any?` reads nicely in the context of specs. I don't think 
I've seen a post mentioning `some?` yet, which surprised me a bit. "Fixing" the 
symmetry of all of this is more than a single name. It is a collection of names 
dating back to 1.0, IIRC. I don't disagree that it would be nice if we could go 
back in time, but generally I think "let it go" is good advice. As an aside, 
the dissonance is more or less consistent. It reminds me a little of 
https://en.m.wikipedia.org/wiki/Multistability.

Perhaps there'll be some liberties taken in 2.0?

Time will tell, but for now I'll echo Alex's suggestion to drop it. This 
particular ship sailed years ago, IMO.

'(Devin Walters)

> On Nov 7, 2016, at 10:23 PM, Mars0i  wrote:
> 
> 
>> Personally I think "any?" and "some?" are aptly named, and that it's the 
>> older "not-any?" and "some" functions that mess things up.
> 
> I can understand the intuition that "not-any?" and "some" are the oddballs, 
> but "Are there any Xs?" and "Are there some Xs?" are true in exactly the same 
> situations.  Or to remove the predicate, since that's what "some" and 
> "not-any?" use: "Is there anything in this thing?" and "Is there something in 
> this thing?" are true in the same situations.  So if some? is aptly named, 
> then any? is not.  (Maybe "anything?" or "something?" would have been better 
> names for some?.)
>  
>> Maybe if Clojure were being designed from scratch again, we'd have something 
>> like "has" and "not-has?", but it's too late to change common function names 
>> now.
> 
> Yeah--too late.
> 
> As well as some still uncommon ones.
> Like "any?".
> :-)
> -- 
> 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: any? in clojure 1.9.0 alpha

[Mars0i]

> Personally I think "any?" and "some?" are aptly named, and that it's the 
> older "not-any?" and "some" functions that mess things up.
>

I can understand the intuition that "not-any?" and "some" are the oddballs, 
but "Are there any Xs?" and "Are there some Xs?" are true in exactly the 
same situations.  Or to remove the predicate, since that's what "some" and 
"not-any?" use: "Is there anything in this thing?" and "Is there something 
in this thing?" are true in the same situations.  So if some? is aptly 
named, then any? is not.  (Maybe "anything?" or "something?" would have 
been better names for some?.)
 

> Maybe if Clojure were being designed from scratch again, we'd have 
> something like "has" and "not-has?", but it's too late to change common 
> function names now.
>

Yeah--too late.

As well as some still uncommon ones.
Like "any?".
:-)

-- 
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 - seeking a working example of stest/instrument with the :replace option

[Joseph Wayne Norton]

Hello.

I tried to construct a small example to understand and to illustrate how 
stest/instrument with the :replace option works.

My attempt to construct a small working example was to expand on the 
ranged-rand example in the clojure.spec Guide.

I created another function called ranged-const that always returns the value of 
the start argument.  I wanted to see if the ranged-const function could become 
a mock to the ranged-rand function.

Here is the behavior that I am seeing.  The mocked ranged-rand should be 
returning 2 but it always returns 5 instead.  Secondly, I would have expected 
to see the printed side-effect of [:ranged-const 2 5].


spec-demo.core=> (stest/instrument `ranged-rand {:replace {`ranged-rand 
::ranged-const}})
[spec-demo.core/ranged-rand]
spec-demo.core=> (ranged-const 2 5)
[:ranged-const 2 5]
2
spec-demo.core=> (ranged-rand 2 5)
5
spec-demo.core=> (ranged-rand 2 5)
5


Any suggestions?

Best regards,

Joe N.


Here is a complete log:

$ cat .boot/boot.properties 
#http://boot-clj.com
#Sat Sep 17 23:34:35 CDT 2016
BOOT_EMIT_TARGET=no
BOOT_CLOJURE_NAME=org.clojure/clojure
BOOT_VERSION=2.6.0
BOOT_CLOJURE_VERSION=1.9.0-alpha14


$ boot repl
nREPL server started on port 53962 on host 127.0.0.1 - nrepl://127.0.0.1:53962
REPL-y 0.3.7, nREPL 0.2.12
Clojure 1.9.0-alpha14
Java HotSpot(TM) 64-Bit Server VM 1.8.0_102-b14
Exit: Control+D or (exit) or (quit)
Commands: (user/help)
Docs: (doc function-name-here)
  (find-doc "part-of-name-here")
Find by Name: (find-name "part-of-name-here")
  Source: (source function-name-here)
 Javadoc: (javadoc java-object-or-class-here)
Examples from clojuredocs.org: [clojuredocs or cdoc]
  (user/clojuredocs name-here)
  (user/clojuredocs "ns-here" "name-here")
boot.user=> (ns spec-demo.core
   #_=>   (:require [clojure.spec :as s]
   #_=> [clojure.spec.test :as stest])
   #_=>   (:gen-class))
nil


spec-demo.core=> (defn ranged-rand
#_=>   "Returns random int in range start <= rand < end"
#_=>   [start end]
#_=>   (println [:ranged-rand start end]) ; DEBUG
#_=>   (+ start (long (rand (- end start)
#'spec-demo.core/ranged-rand 

spec-demo.core=> (s/fdef ranged-rand
#_=> :args (s/and (s/cat :start int? :end int?)
#_=>  #(< (:start %) (:end %)))
#_=> :ret int?
#_=> :fn (s/and #(>= (:ret %) (-> % :args :start))
#_=>#(< (:ret %) (-> % :args :end
spec-demo.core/ranged-rand

spec-demo.core=> (defn ranged-const
#_=>   "Returns const int equal to start such that start <= const < 
end"
#_=>   [start end]
#_=>   (println [:ranged-const start end]) ; DEBUG
#_=>   start)
#'spec-demo.core/ranged-const

spec-demo.core=> (s/fdef ranged-const
#_=> :args (s/and (s/cat :start int? :end int?)
#_=>  #(< (:start %) (:end %)))
#_=> :ret int?
#_=> :fn #(= (:ret %) (-> % :args :start)))
spec-demo.core/ranged-const
spec-demo.core=> (ranged-rand 2 5)
[:ranged-rand 2 5]
3
spec-demo.core=> (ranged-rand 2 5)
[:ranged-rand 2 5]
4
spec-demo.core=> (ranged-rand 2 5)
[:ranged-rand 2 5]
2
spec-demo.core=> (ranged-const 2 5)
[:ranged-const 2 5]
2
spec-demo.core=> (ranged-const 2 5)
[:ranged-const 2 5]
2
spec-demo.core=> (ranged-const 2 5)
[:ranged-const 2 5]
2

spec-demo.core=> (stest/instrument `ranged-rand {:replace {`ranged-rand 
::ranged-const}})
[spec-demo.core/ranged-rand]
spec-demo.core=> (ranged-const 2 5)
[:ranged-const 2 5]
2
spec-demo.core=> (ranged-rand 2 5)
5
spec-demo.core=> (ranged-rand 2 5)
5
spec-demo.core=> (ranged-rand 2 5)
5
spec-demo.core=> 

-- 
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: Clarification on # as valid symbol character

[Alex Miller]

On Monday, November 7, 2016 at 6:33:49 PM UTC-6, Steven Yi wrote:
>
> Hi All, 
>
> I wanted to understand whether '#' may be treated as a valid character 
> for symbols. The Clojure site [1] has: 
>
> "Symbols begin with a non-numeric character and can contain 
> alphanumeric characters and *, +, !, -, _, ', and ? (other characters 
> may be allowed eventually)." 
>

The general advice here is that the characters listed here are guaranteed 
to be valid now and in the future. Characters not listed here may be 
accepted now or used within Clojure, but are not guaranteed to work in the 
future.
 

> I realized I was using # today in a symbol without thinking much of 
> it. However, the syntax highlighting in Vim marked it oddly when it 
> was at the end of the symbol name versus in the middle of the name. 
> (The use case is denoting musical notes using lists of symbols, such 
> as '(c c# d eb) ). 
>

Same as above - this works now, but is not guaranteed to always be valid.

auto-gensyms also employ # as part of symbol names, but I do not know 
> if that should be considered a kind of special case. 
>

Same as above - Clojure may use these symbols to mean special things (like 
auto gensyms in syntax quote), but that right is reserved for Clojure.
 

> Any clarifications appreciated! 
> steven 
>
> [1] - http://clojure.org/reference/reader 
>

-- 
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: Clarification on # as valid symbol character

[Ikuru Kanuma]

Hi Steven!

I think all of those cases are covered in the reader reference' reader 
dispatch section:
http://clojure.org/reference/reader#_dispatch

Basically when the reader encounters a '#' it does the appropriate dispatch 
action depending on what follows.
As it is a special character handled by the reader it would not make a 
valid symbol character (To answer you original question).

Ikuru

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

Clarification on # as valid symbol character

[Steven Yi]

Hi All,

I wanted to understand whether '#' may be treated as a valid character
for symbols. The Clojure site [1] has:

"Symbols begin with a non-numeric character and can contain
alphanumeric characters and *, +, !, -, _, ', and ? (other characters
may be allowed eventually)."

I realized I was using # today in a symbol without thinking much of
it. However, the syntax highlighting in Vim marked it oddly when it
was at the end of the symbol name versus in the middle of the name.
(The use case is denoting musical notes using lists of symbols, such
as '(c c# d eb) ).

auto-gensyms also employ # as part of symbol names, but I do not know
if that should be considered a kind of special case.

Any clarifications appreciated!
steven

[1] - http://clojure.org/reference/reader

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

Re: clojure.spec gen-testing VS NaN

[dimitris]

Alright cool, I'll do that tomorrow :)

Thanks,

Dimitris


On 07/11/16 22:07, Alex Miller wrote:
I think it would be reasonable to log a jira enhancement request for 
the spec any? generator to avoid generating double NaNs.



On Monday, November 7, 2016 at 12:30:24 PM UTC-6, Jim foo.bar wrote:

Hi Alex,

Oh yeah I've seen `s/double-in` but as you point out that doesn't
help me if I want to :ret spec a function with similar semantics
as remove (a fn that transforms a seq given a predicate), which I
find a very common indeed.  I'm only starting playing with
clojure.spec (in fact i've only spec'ed 2 fns so far) and I've not
yet had to spec specifically a double-precision number. I have had
however the need to spec :any? as ::anything-but-NaN, in both my
first 2 specs, so according to my experience this is by no means a
rare issue. In fact, looking at clojure.core, most fns operate on
seqs, and a good proportion of them processes/transforms a coll
according to a predicate/fn. This has nothing to do with doubles
or in fact numbers. We can only spec the contents of the
collection as `any?` right? anything more specific, and the
gen-surface area is reduced. So yeah it's great that we have
`s/double-in`, but ideally I'd also like a reliable way to say
that the output coll from a fn is equal to the input coll, while
having specified the contents of that coll with `any?`, and
without having to jump through hoops in the :ret spec. My
workaround is actually working nicely for me, and i can certainly
live without NaNs in the tests, but it still feels a bit hacky.

Thanks,

Dimitris


On 07/11/16 18:14, Alex Miller wrote:

Please also take a look at s/double-in, which allows you to
exclude NaN (and Infinity/-Infinity) as valid values.

(I realize this does not address the any? question, but that
seems like a rarer issue to me than cases where I'm explicitly
spec'ing a double but don't want to allow NaN.)

On Monday, November 7, 2016 at 11:37:08 AM UTC-6, Jim foo.bar wrote:

Hi all,

clojure.spec helped me realise that NaNs totally break [1]
equality (per
`clojure.core/=`). Even though in real production code this
might not be
an issue due to how infrequently one deals with NaNs, but during
gen-testing I've found them extremely annoying, and I've
essentially
worked around this by spec-ing things I'd normally specify
via `any?`,
via `(s/and any? (complement double-NaN?))` instead. I have
to do this
for any spec, where in the :ret spec i need to be able to
confirm that
the input coll is equal to the output coll (e.g.
`clojure.core/remove`
returns the same coll it was passed in when nothing has been
removed),
which is a possibility in a lot of functions. Have other people
encountered this as well, and if yes, how are you guys
dealing with it?
Thanks in advance...

Kind regards,

Dimitris

[1]: (= [:a Double/NaN] [:a Double/NaN]) => false



-- 
You received this message because you are subscribed to the Google

Groups "Clojure" group.
To post to this group, send email to 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

Re: clojure.spec gen-testing VS NaN

[Alex Miller]

I think it would be reasonable to log a jira enhancement request for the 
spec any? generator to avoid generating double NaNs.


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

[Alex Miller]

The problem here is that you're not giving the Clojure type inferencing 
enough info to work with and it's using reflection to find the correct 
method. When it finds multiple potential matching methods by arity, it 
calls an arbitrary one (not my favorite behavior). So, not a feature and 
maybe a bug (or maybe just "undefined behavior", depending how you think 
about it). 

The start of the problem is that br is not automatically given a type - 
it's just treated as an Object. So the method getBaseNullSupplier is 
invoked reflectively and the return type of that is just defaulted to 
Object, which means it will reflectively find multiple matches for method_ 
and may call any of them.

The simplest fix is to tag your br var with it's type:

(def ^SupplierRouter br (new SupplierRouter))

Then the inferencer can figure out the rest of it automatically. 

Alternately, you could tag just the first call with br:

(println (. br method_ (. ^SupplierRouter br getBaseNullSupplier)))

And that should be enough as well. If this was in a function, I would tag 
the incoming parameter instead.




On Sunday, November 6, 2016 at 10:02:42 AM UTC-6, Alexey Stepanov wrote:
>
> Hello!
>
> I experimented with overload resolution. And faced with a strange 
> behavior.
>
> https://gist.github.com/alejes/355881c1711224d5a773fbf0275b4898
>
> The Clojure code calls a method from the Java. But at different runs I get 
> the result call different methods (4 and 6). 
> It is a simplified version of the example which I encountered. In the 
> original version it periodically called method #0. However, in the 
> simplified example I is not noticed call #0 method.
>
> It is a bug or feature? Can someone explain why is this happening?
>
> 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: code from spec with clojure.spec?

[Alex Miller]

On Monday, October 17, 2016 at 5:51:42 PM UTC-5, Joe Corneli wrote:
>
> As a running example related to the ideas in 
> http://clojure.org/guides/spec#_spec_ing_functions, please consider the 
> following function:
>
> (defn mapper [x y]
>   {:tacos (vec (range x))
>:burritos (vec (range y))})
>
> Example input and output:
>
> (mapper 2 4) ;=> {:tacos [0 1], :burritos [0 1 2 3]}
>
> OK, I'll go ahead and write a sensible-seeming spec for this function now, 
> as follows:
>
> (s/fdef mapper
> :args (s/cat :t (s/and integer? #(> % 0))
>  :b (s/and integer? #(> % 0)))
>

An aside: you can use `pos?` for the latter half of those specs (or just 
replace the whole thing with pos-int? if you're ok with just fixed 
precision integers).
 

>
> :ret map?
> :fn (s/and #(= (-> % :ret :tacos)
>(vec (range (-> % :args :t
>#(= (-> % :ret :burritos)
>(vec (range (-> % :args :b))
>
> My first question: Is there a way to only write the spec, and have the 
> function generated automatically?  
>

In short, no.
 

> The behavior I have in mind is (after all) specified in the :fn part of 
> the fdef. 
>

There is a definite art to writing :fn specs that a) check something useful 
and b) don't actually repeat the code that is actually in the function. I 
think this particular spec is more than I would likely try to spec but I 
don't know that there is a single right answer.
 

> And, another somewhat related question: if I redefine the function to do 
> nothing, and then exercise it, I get output that doesn't seem to conform to 
> the :fn condition given above, but no error -- why is that?
>

See my answer in the other thread - the generated function just generates 
return values according to the :ret spec, without regard to the args 
passed. Use a custom generator for the function if you want/need that.
 

> (defn mapper [x y])
> (s/exercise-fn `mapper)
> ;=> ([(1 3) nil] [(1 1) nil] [(4 2) nil] [(2 3) nil] [(6 3) nil] [(15 
> 2633) nil] [(3 1) nil] [(3 4) nil] [(1 1) nil] [(28 4) nil])
>
> Thanks for any help!
>

-- 
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 predicate generator question

[Alex Miller]

On Sunday, November 6, 2016 at 5:01:23 AM UTC-6, Jim foo.bar wrote:
>
> Hi all,
>
> Without having looked at the test.check internals, I'm trying to figure 
> out roughly what kind of generator function, the following spec will give:
>
> (s/def ::predicate  (s/fspec :args (s/cat :x any?)
>  :ret boolean?))
>
>
fdef or fspec will generate a function that checks that assert the incoming 
args match the :args spec and then return a value generated by the :ret 
spec.

 

> So, I'm trying to sort of reverse engineer it on the repl:
>
> (def p (second (first (s/exercise ::predicate 1
> => #'specs.encore/p
> p
> =>
> #object[clojure.spec$fspec_impl$reify__14282$fn__14285
> 0x5cb07a8d
> "clojure.spec$fspec_impl$reify__14282$fn__14285@5cb07a8d"]
> (p 1)
> => false
> (p [])
> => false
> *(p :a)*
> *=> true *
> (p :b)
> => false
> *(p :a)*
> *=> true*
> *(p :a)*
> *=> false* 
>
> Ok, so the predicate returned does not always return the same boolean 
> value (so not constructed via `constantly`). But it also returns a 
> different boolean, given the same argument (so not a real predicate in the 
> sense that it looks at the argument and then decides)! Only one option 
> remains, as far as I can see...`p` seems to return true or false randomly. 
> Can anyone confirm this?
>

This is consistent with my description above.
 

> If my understanding is correct, how would one write the :fn spec of a 
> function like `clojure.core/remove`? Wouldn't it make sense to try to 
> verify that the :ret collection does NOT contain any elements satisfying 
> the predicate used? Similarly for `clojure.core/filter`. A reasonable :fn 
> spec for it should try to confirm that ALL elements in :ret  satisfy that 
> predicate used, right? But if the predicate generated returns true/false 
> randomly, one cannot reliably use it under the :fn spec. Unless, I'm 
> missing something of course...Thanks in advance :)
>

You can write a :fn spec that does all of those things, however the 
generated function spec will not verify those. It would maybe be a 
reasonable enhancement to verify that the :fn spec is satisfied wrt the 
passed args and the generated :ret value (by adding a such-that generator 
based that enhances the ret generator. This is likely to make function 
generators work harder / fail more easily, but you would have greater 
guarantees when it did pass. Seems worthy of an enhancement ticket.

You can use stest/instrument to supply alternative specs and/or generator 
overrides for a function and that would be my recommended strategy right 
now.
 

> Kind regards,
>
> Dimitris
>
>
>
>
>
>

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

Re: clojure.spec gen-testing VS NaN

[dimitris]

Hi Alex,

Oh yeah I've seen `s/double-in` but as you point out that doesn't help 
me if I want to :ret spec a function with similar semantics as remove (a 
fn that transforms a seq given a predicate), which I find a very common 
indeed.  I'm only starting playing with clojure.spec (in fact i've only 
spec'ed 2 fns so far) and I've not yet had to spec specifically a 
double-precision number. I have had however the need to spec :any? as 
::anything-but-NaN, in both my first 2 specs, so according to my 
experience this is by no means a rare issue. In fact, looking at 
clojure.core, most fns operate on seqs, and a good proportion of them 
processes/transforms a coll according to a predicate/fn. This has 
nothing to do with doubles or in fact numbers. We can only spec the 
contents of the collection as `any?` right? anything more specific, and 
the gen-surface area is reduced. So yeah it's great that we have 
`s/double-in`, but ideally I'd also like a reliable way to say that the 
output coll from a fn is equal to the input coll, while having specified 
the contents of that coll with `any?`, and without having to jump 
through hoops in the :ret spec. My workaround is actually working nicely 
for me, and i can certainly live without NaNs in the tests, but it still 
feels a bit hacky.


Thanks,

Dimitris


On 07/11/16 18:14, Alex Miller wrote:
Please also take a look at s/double-in, which allows you to exclude 
NaN (and Infinity/-Infinity) as valid values.


(I realize this does not address the any? question, but that seems 
like a rarer issue to me than cases where I'm explicitly spec'ing a 
double but don't want to allow NaN.)


On Monday, November 7, 2016 at 11:37:08 AM UTC-6, Jim foo.bar wrote:

Hi all,

clojure.spec helped me realise that NaNs totally break [1]
equality (per
`clojure.core/=`). Even though in real production code this might
not be
an issue due to how infrequently one deals with NaNs, but during
gen-testing I've found them extremely annoying, and I've essentially
worked around this by spec-ing things I'd normally specify via
`any?`,
via `(s/and any? (complement double-NaN?))` instead. I have to do
this
for any spec, where in the :ret spec i need to be able to confirm
that
the input coll is equal to the output coll (e.g.
`clojure.core/remove`
returns the same coll it was passed in when nothing has been
removed),
which is a possibility in a lot of functions. Have other people
encountered this as well, and if yes, how are you guys dealing
with it?
Thanks in advance...

Kind regards,

Dimitris

[1]: (= [:a Double/NaN] [:a Double/NaN]) => false



--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to 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 gen-testing VS NaN

[Alex Miller]

Please also take a look at s/double-in, which allows you to exclude NaN 
(and Infinity/-Infinity) as valid values.

(I realize this does not address the any? question, but that seems like a 
rarer issue to me than cases where I'm explicitly spec'ing a double but 
don't want to allow NaN.)

On Monday, November 7, 2016 at 11:37:08 AM UTC-6, Jim foo.bar wrote:
>
> Hi all, 
>
> clojure.spec helped me realise that NaNs totally break [1] equality (per 
> `clojure.core/=`). Even though in real production code this might not be 
> an issue due to how infrequently one deals with NaNs, but during 
> gen-testing I've found them extremely annoying, and I've essentially 
> worked around this by spec-ing things I'd normally specify via `any?`, 
> via `(s/and any? (complement double-NaN?))` instead. I have to do this 
> for any spec, where in the :ret spec i need to be able to confirm that 
> the input coll is equal to the output coll (e.g. `clojure.core/remove` 
> returns the same coll it was passed in when nothing has been removed), 
> which is a possibility in a lot of functions. Have other people 
> encountered this as well, and if yes, how are you guys dealing with it? 
> Thanks in advance... 
>
> Kind regards, 
>
> Dimitris 
>
> [1]: (= [:a Double/NaN] [:a Double/NaN]) => false 
>
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to 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 gen-testing VS NaN

[dimitris]

Hi all,

clojure.spec helped me realise that NaNs totally break [1] equality (per 
`clojure.core/=`). Even though in real production code this might not be 
an issue due to how infrequently one deals with NaNs, but during 
gen-testing I've found them extremely annoying, and I've essentially 
worked around this by spec-ing things I'd normally specify via `any?`, 
via `(s/and any? (complement double-NaN?))` instead. I have to do this 
for any spec, where in the :ret spec i need to be able to confirm that 
the input coll is equal to the output coll (e.g. `clojure.core/remove` 
returns the same coll it was passed in when nothing has been removed), 
which is a possibility in a lot of functions. Have other people 
encountered this as well, and if yes, how are you guys dealing with it? 
Thanks in advance...


Kind regards,

Dimitris

[1]: (= [:a Double/NaN] [:a Double/NaN]) => false



--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to 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 - relationship between :args

[dimitris]

Hi Michal,

Oh yeah,  I've actually improved the spec I shared over the weekend, in 
a similar direction you're hinting. Basically, i've split the :found & 
:not-found cases, and using `gen/one-of`. Many thanks :)


regards,

Dimitris




On 07/11/16 11:41, Michał Marczyk wrote:
Only one quick bit of feedback – it's preferable to use test.check 
facilities instead of (rand) because they're "repeatable": the seed 
emitted in test.check output can be used to rerun the test with the 
same test.check PRNG state (see the docstring on 
clojure.test.check/quick-check, specifically the :seed option), but if 
you call out to other PRNGs, you defeat that mechanism and you'll 
still get different results on different runs. So here you might want 
to say (gen/elements [:head :tails]).


Cheers,
Michał


On 5 November 2016 at 11:59, dimitris > wrote:


Hi Alex,

I think I've figured it out. Here is the complete solution I've
come up with in case you feel like providing feedback:

(defn- extract-sensible-k-gen
   "Gen override for `::extract-args`." []
   (gen/bind (spc/gen ::persistent-coll)
 #(let [r (rand)
heads? (>= r0.5)];; flip a coin (gen/tuple (gen/elements (cond 
(empty? %) (repeat 2 :NOT-FOUND);; nothing can be possibly found in an empty coll 
(map? %) (if heads?
 (keys %);; keys that will be found (repeat 2 
:NOT-FOUND));; keys that will not be found (set? %) (if heads?
 %;; elements (repeat 2 :NOT-FOUND))
  (sequential? %) (let [c (count %)]
(if heads?;; index overrides (if (> r0.75)
(range c);;valid indices (concat (range 
-1 (dec (- c))-1);; invalid (negative) indices (range c (+ c10
  (if (> r0.25);; predicate overrides 
(repeat 2 (constantly true))
(repeat 2 (constantly false)
  ))
  (gen/return %)))
 ))


;==
(spc/def ::persistent-coll (spc/or :map (spc/map-of any? any?)
 :vector (spc/coll-of any?:kind vector?)
 :set (spc/coll-of any?:kind set?)
 :list (spc/coll-of any?:kind list?)))

(spc/def ::predicate (spc/fspec :args (spc/cat :x any?) :ret boolean?))

(spc/def ::extract-args (spc/cat :k (spc/or :predicate ::predicate 
:key-or-index any?)
:coll ::persistent-coll))

(spc/fdef enc/extract

   :args ::extract-args :ret (spc/tuple any? coll?) :fn (spc/or
:some-found #(let [[e c] (:ret %)
[coll-type arg-coll] (-> %:args :coll)]
   (and (some? e)
(> (count arg-coll)
   (count c))
#_(do (println "SOME-FOUND - cret=" c "argc=" 
arg-coll \newline
(-> % :args :k second)) true) )) :nil-found #(let [[e c] (:ret %)
   [coll-type arg-coll] (-> %:args :coll)]
  (and (nil? e)
   (> (count arg-coll)
  (count c))
   #_(do (println "NIL-FOUND - cret=" c "argc=" 
arg-coll \newline (->
% :args :k second)) true) )) :not-found #(let [[e c] (:ret %)
   [coll-type arg-coll] (-> %:args :coll)]
  (and (nil? e)
   (= arg-coll c)
   #_(do (println "NOT-FOUND - cret=" c "argc=" 
arg-coll \newline (->
% :args :k second)) true) )))
   )

 and i call it like so:

(-> (test/check `treajure.encore/extract {:gen {::extract-args 
extract-sensible-k-gen}})
 test/summarize-results

I must say, i was surprised to see that my humble 8G-ram laptop
can barely deal with the default number of generative tests
(1000), but at least it works :).

Many thanks again, for redirecting me to Stu's video - it all made
much more sense after digesting that.

Regards,

Dimitris

On 04/11/16 00:14, dimitris wrote:


HI Alex,

Many thanks for your response, it was very helpful. I see your
point about customizing the generator, and in fact the video in
the link does something sort of similar to what I am trying to.
So yeah I'll figure it out tomorrow :). Thanks again!

Dimitris

On 03/11/16 18:53, Alex Miller wrote:

On Thursday, November 3, 2016 at 1:12:39 PM UTC-5, Jim foo.bar
wrote:

Hi everyone,

I'm starting to get familiar with clojure.spec, and in my
very first spec I needed to specify relationship between the
args themselves (similar to how :fn specs allow for
specifying some relationship between :args & :ret). Is that
  

Re: any? in clojure 1.9.0 alpha

[James Reeves]

On 7 November 2016 at 02:47, waffletower 
wrote:

> I disagree, the new implementation is a subset of the code I presented.
> Here is the docstring from 1.9.0-alpha14
>

Disagree with what? I don't understand your answer.

A semantically consistent implementation of (any?), given the current
> implementation of (not-any?) would provide a similar function prototype
> where an arbitrary predicate function would evaluate against a collection.
>

Your "semantically consistent implementation of (any?)" already exists in
the language. It's called "some".

Personally I think "any?" and "some?" are aptly named, and that it's the
older "not-any?" and "some" functions that mess things up.

Maybe if Clojure were being designed from scratch again, we'd have
something like "has" and "not-has?", but it's too late to change common
function names now.

- James

-- 
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 - relationship between :args

[Michał Marczyk]

Only one quick bit of feedback – it's preferable to use test.check
facilities instead of (rand) because they're "repeatable": the seed emitted
in test.check output can be used to rerun the test with the same test.check
PRNG state (see the docstring on clojure.test.check/quick-check,
specifically the :seed option), but if you call out to other PRNGs, you
defeat that mechanism and you'll still get different results on different
runs. So here you might want to say (gen/elements [:head :tails]).

Cheers,
Michał


On 5 November 2016 at 11:59, dimitris  wrote:

> Hi Alex,
>
> I think I've figured it out. Here is the complete solution I've come up
> with in case you feel like providing feedback:
>
> (defn- extract-sensible-k-gen
>   "Gen override for `::extract-args`."  []
>   (gen/bind(spc/gen ::persistent-coll)
> #(let [r (rand)
>heads? (>= r 0.5)] ;; flip a coin   (gen/tuple 
> (gen/elements   (cond (empty? %) (repeat 2 :NOT-FOUND) ;; 
> nothing can be possibly found in an empty coll (map? %) (if heads?
> (keys %) ;; keys that will be found   
>  (repeat 2 :NOT-FOUND)) ;; keys that will not be found (set? 
> %) (if heads?
> % ;; elements(repeat 2 
> :NOT-FOUND))
>  (sequential? %) (let [c (count %)]
>(if heads? ;; index overrides  
>(if (> r 0.75)
>(range c) ;;valid indices  
>  (concat (range -1 (dec (- c)) -1) ;; invalid (negative) 
> indices   (range c (+ c 10
>  (if (> r 0.25) ;; predicate overrides
>(repeat 2 (constantly true))
>(repeat 2 (constantly false)
>  ))
>  (gen/return %)))
> ))
>
> ;==(spc/def
>  ::persistent-coll  (spc/or:map (spc/map-of any? any?)
> :vector (spc/coll-of any? :kind vector?)
> :set (spc/coll-of any? :kind set?)
> :list (spc/coll-of any? :kind list?)))
>
> (spc/def ::predicate  (spc/fspec :args (spc/cat :x any?)
>  :ret boolean?))
>
> (spc/def ::extract-args  (spc/cat :k (spc/or:predicate 
> ::predicate:key-or-index any?)
>:coll ::persistent-coll))
>
> (spc/fdef enc/extract
>
>   :args ::extract-args  :ret (spc/tuple any? coll?)
>
>   :fn (spc/or:some-found #(let [[e c] (:ret %)
>[coll-type arg-coll] (-> % :args :coll)]
>   (and (some? e)
>(> (count arg-coll)
>   (count c))
>#_(do (println "SOME-FOUND - cret=" c "argc=" 
> arg-coll \newline (-> % :args :k second))   true) 
>   ))
> :nil-found #(let [[e c] (:ret %)
>   [coll-type arg-coll] (-> % :args :coll)]
>  (and (nil? e)
>   (> (count arg-coll)
>  (count c))
>   #_(do (println "NIL-FOUND - cret=" c "argc=" 
> arg-coll \newline (-> % :args :k second))  true)  
> ))
> :not-found #(let [[e c] (:ret %)
>   [coll-type arg-coll] (-> % :args :coll)]
>  (and (nil? e)
>   (= arg-coll c)
>   #_(do (println "NOT-FOUND - cret=" c "argc=" 
> arg-coll \newline (-> % :args :k second))  true)  
> )))
>   )
>
>  and i call it like so:
>
> (-> (test/check `treajure.encore/extract {:gen {::extract-args 
> extract-sensible-k-gen}})
> test/summarize-results
>
> I must say, i was surprised to see that my humble 8G-ram laptop can barely
> deal with the default number of generative tests (1000), but at least it
> works :).
>
> Many thanks again, for redirecting me to Stu's video - it all made much
> more sense after digesting that.
>
> Regards,
>
> Dimitris
>
> On 04/11/16 00:14, dimitris wrote:
>
> HI Alex,
>
> Many thanks for your response, it was very helpful. I see your point about
> customizing the generator, and in fact the video in the link does something
> sort of similar to what I am trying to. So yeah I'll figure it out tomorrow
> :). Thanks again!
>
> Dimitris
>
> On 03/11/16 18:53, Alex Miller wrote:
>
>
>
> On Thursday, November 3, 2016 at 1:12:39 PM UTC-5, Jim foo.bar wrote:
>>
>> Hi everyone,
>>
>> I'm starting to get familiar with clojure.spec, and in my very first spec
>> I needed to specify relationship between the args themselves (similar to
>> how :fn specs allow for 

Re: any? in clojure 1.9.0 alpha

[Ravindra Jaju]

[Inconsequential email]

On Mon, Nov 7, 2016 at 11:46 AM, Mars0i  wrote:

> "any?" wasn't the only option.  I would have gone with something obvious
> like "always-true", or "yes", or even something possibly too-clever like
> "arg-or-not-arg?" or "or-not-this?"  These last might be confusing, but not
> misleading, as "any?" is.
>
>
I like "yes" - there's a close Unix precedent too. Not 1-to-1, but close
enough in spirit.

-- 
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: any? in clojure 1.9.0 alpha

[Colin Yates]

That discussion has left quite a sour taste in my mouth. Naming is so
important and to be blunt, this name is awful:
 - breaks the ubiquitous language of English which already has a very
well defined definition of 'any' and those semantics aren't it
 - breaks the ubiquitous language of Clojure which already has a very
well defined definition for 'predicate'? named fns
 - disregards the very important principle of 'least surprise'
 - is justified and motivated by a very specific contextual use (specs)

The shutting down by Alex is fair enough I think. Clojure was, and
probably will be for the foreseeable future led by a very small,
closely knit design group. Nothing wrong with that.

I am genuinely surprised by this pretty poor engineering on the basis
of a number of pretty fundamental principles. I think "it makes sense
over here" and "b does the semantics associated by a" are both smells
of poor design.

Now, after all that moaning I had better go before somebody asks me
where my perfect bit of software engineering is. Of course, I have
one, but it is unfortunately closed source :-) :-).


On 7 November 2016 at 03:54, Alan Thompson  wrote:
> There was quite a discussion of this topic back in July if you'd like to
> review it:   https://goo.gl/Azy8Nf
>
> The semantic mismatch is unfortunate.
> Alan
>
> On Sun, Nov 6, 2016 at 6:47 PM, waffletower 
> wrote:
>>
>> I disagree, the new implementation is a subset of the code I presented.
>> Here is the docstring from 1.9.0-alpha14
>>
>> (doc any?)
>> -
>> clojure.core/any?
>> ([x])
>>   Returns true given any argument.
>>
>> There isn't a predicate function argument as in (not-any?):
>>
>> (doc not-any?)
>> -
>> clojure.core/not-any?
>> ([pred coll])
>>   Returns false if (pred x) is logical true for any x in coll,
>>   else true.
>>
>> A semantically consistent implementation of (any?), given the current
>> implementation of (not-any?) would provide a similar function prototype
>> where an arbitrary predicate function would evaluate against a collection.
>>
>> On Sunday, November 6, 2016 at 5:05:45 PM UTC-8, James Reeves wrote:
>>>
>>> On 6 November 2016 at 23:31, waffletower  wrote:

 I find the semantic of the new (any?) function to be in conflict with
 (not-any?) and a strange addition, at least with the chosen name.  This
 concern has come up on the "clojure dev" group as well.   I have found a
 different implementation of (any?) useful in my own projects:

 (defn any?
   [pred coll]
   (not (not-any? pred coll)))

 I found it odd that (not-any? pred coll) existed without (any? pred
 coll).
>>>
>>>
>>> The clojure.core/some function does effectively the same thing as your
>>> any? function.
>>>
>>> - James
>>
>> --
>> 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