Re: any? in clojure 1.9.0 alpha

[Mars0i]

On Monday, November 7, 2016 at 12:16:28 AM UTC-6, 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?" 
>
 
Or maybe:
"argument?"
"value?"
"is-something?"
"is-a-clojure-value?"
"surrounding-expression-compiled?" (Since if the expression is not true, 
that's because it didn't compile.)

Or, obliquely inspired by Descartes 
: 
"i-am?"

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

On Sunday, November 6, 2016 at 9:54:19 PM UTC-6, 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
>

 It's not just a mismatch with not-any?, though.  "any?" makes no sense as 
a name for a function that returns true no matter what is passed to it.  
That's not what "any" means in English.  

Alex Miller ended the discussion by stating that it was not up for debate.  
(So the rest of this post will affect nothing, and there are good reasons 
to stop reading.)

My respect for Alex (and Rich) is very, very great, but I think this 
choice, and the decision to shut down discussion of it when spec is still 
alpha is, yeah, unfortunate.  Not that it matters now.  But alpha was the 
time to discuss it.

Similar to points I've made before:  There are lots of things I like about 
Clojure, and lots of reasons that I am happier using Clojure than Common 
Lisp.  Here's one: Common Lisp sometimes uses a confusing hodgepodge of 
function names, sometimes with differently named functions that do similar 
things, with different argument orders and different semantics in other 
respects.  I assume that this is because CL was defined by a committee, and 
in particular a committee that wanted to merge independently-developed 
dialects of Lisp.  Clojure, by contrast, was not designed by committee, and 
was designed from the start to have an elegant system of functions and 
function names.  Not perfect in this respect, but still beautiful.  It 
makes Clojure easier to learn, easier to understand, and makes it easier to 
remember function names and semantics.  So it bugs me when Clojure takes a 
step toward arbitrary quirkiness.  

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

(But none of that matters.)

(There is an upside to quirkiness, however.  if you program in CL for a 
bit, you get to experience the pride of your esoteric knowledge of the ins 
and outs of CL's functions.)

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

[Alan Thompson]

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.

Re: any? in clojure 1.9.0 alpha

[waffletower]

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.

Re: any? in clojure 1.9.0 alpha

[James Reeves]

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.

any? in clojure 1.9.0 alpha

[waffletower]

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


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

Strange behavior Clojure and Null

[Alexey Stepanov]

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?

[Joe Corneli]

This is a late reply to my own question but maybe it will be helpful to a 
future searcher.

http://blog.cognitect.com/blog/2016/10/5/interactive-development-with-clojurespec
has an example that showed me more clearly how to use :fn.

Specifically here's how I rewrote the spec:

(s/fdef mapper
:args (s/cat :t :fake.flowrs-tests/positive-integer?
 :b :fake.flowrs-tests/positive-integer?)
:ret map?
:fn (fn [{args :args ret :ret}]
  (= (:tacos ret)
 (vec (range (:t args
  (= (:burritos ret)
 (vec (range (:b args))

(s/exercise-fn `mapper) has the same behavior as before -- it exercises the 
*implementation* of the function.  But (stest/check `mapper) will return 
"Specification-based 
check failed" etc. when the implementation of mapper doesn't match.

As for the other part of the question: turning the logical test of :fn into 
a function that can be run to generate the result, that would require quite 
a bit of code rewriting.  A partial step is just to extract the :fn part of 
the code, and that can be done as follows:

(:fn (apply hash-map (rest (s/form (get (s/registry) 
'fake.flowrs/mapper)
;=>
(clojure.core/fn
 [{args :args, ret :ret}]
 (clojure.core/=
  (:tacos ret)
  (clojure.core/vec (clojure.core/range (:t args
 (clojure.core/=
  (:burritos ret)
  (clojure.core/vec (clojure.core/range (:b args)

The function so-obtained can be evaluated, but it won't "do" the job of the 
mapper function without further code transformation.  I'll leave it at that 
for now.

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

[dimitris]

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

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?


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


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.