Re the discussion around some?/if-some/when-some...
Summarizing feedback here:
1) "some?" has a confusion with "some" (but some congruence with some->,
some->>)
2) other names might be better (not-nil?, nnil?, exists?, value?)
3) if-some and when-some lack the word "let" to clue you into their bi
CLJ-700 is a bug, regardless of whether it is marked as alpha or not.
This ticket has a strange history of approval statuses (pre-dating my
involvement with jira) that caused it not to be included in 1.6 earlier.
Unfortunately, I think it is too big a change to consider at this point in
1.6 (d
Since transients are no longer marked as alpha, I want to take this (last?)
chance to raise an interface question concerning them:
Right now, we cannot distinguish whether a transient contains a key with a
nik value or if it doesn't contain the key, because contains? doesn't work
on transients.
Is
I like Alex's suggestions. Another option is "something" rather than
"some" or "exists". "Something" has the disadvantage that it's long, so
when you combine it with addition strings, you get something even longer.
On the other hand, for me both "some" and "exists" sound like existential
qu
Part of Rich's objection to not-nil? variants could be that they are a
double negative, "not-(no value)?", which can decrease clarity and require
more coffee.
>- nil Means 'nothing/no-value'- represents Java null and tests logical
>false [clojure.org/reader]
>
>
To compete with some? v
Like this, just
not-nil?
if-not-nil
when-not-nil
is much better for me.
суббота, 15 февраля 2014 г., 7:12:21 UTC+4 пользователь Joel Holdbrooks
написал:
>
> As an addendum to my last comment, *not-nil?* would also be a good
> candidate. That really doesn't leave room for doubt.
>
> This:
>
Great job on the new release guys :)
My one bit of feedback is that if-some and when-some behave like a let, but
don't include "let" in the name. My guess is that this was chosen because
if-some-let and when-some-let are starting to get awkwardly long.
On Sat, Feb 15, 2014 at 2:32 PM, Andy Fing
Alex's suggestion is a good way to determine whether the 10k clj-tuples in
a set case is being sped up by the new hash function -- just look at the
variety of values of (hash x) for all x's in the set and see whether it is
significantly more unique hash values in 1.6.0-beta1 than with 1.5.1.
As fo
Actually, truthy? = boolean.
Anyway, throw everything I said in the trash. :-) No more sleepy posts to the
ML from me.
On February 15, 2014 at 1:02:43 PM, Alex Miller (a...@puredanger.com) wrote:
truthy? = identity
falsey? = not
--
You received this message because you are subscribed to
That’s fair.
On February 15, 2014 at 1:02:43 PM, Alex Miller (a...@puredanger.com) wrote:
truthy? = identity
falsey? = not
--
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
truthy? = identity
falsey? = not
--
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 fro
Thank you for all of the very helpful answers about nil and "some". I
understand now.
I am *very* grateful to Rich Hickey and all of the other dedicated Clojure
developers. For what it's worth, I'll add my voice to those who are
bothered by the two distinct uses of "some" (some, some-fn vs so
Thank you for all of the very helpful answers about nil and "some". I
understand now.
I am *very* grateful to Rich Hickey and all of the other dedicated Clojure
developers. For what it's worth, I'll add my voice to those who are
bothered by the two distinct uses of "some" (some, some-fn vs so
Thanks for all of the very helpful answers about nil and "some". I
understand now. I'll add my voice to those who are bothered by the two
distinct uses of "some" (some, some-fn vs some->, some->>, some?) bother
me.
I celebrate the semi-arbitrary quirkiness of function names in Common Lisp,
inline
On Saturday, February 15, 2014 12:41:52 AM UTC-5, Mars0i wrote:
>
> Could someone clarify for me why "some?" as a name for not nil makes sense
> at all in the first place? Not criticizing. I just don't understand what
> existence or there being some of something has to do with nil.
>
>
I'd agree with all that. One place we've seen nil but not false become more
prevalent lately is in core.async. Channels reserve special meaning for nil
(closed) but false is a valid channel value. So if-some and when-some are
particularly useful in go loops that take from a channel. There are a
Thanks! Great to hear positive benchmark results. I'd guess that if you did
(count (distinct (map hash your-set))) you'd see that was a lot smaller than
(count your-set) in 1.5.1 indicating hash collisions.
--
You received this message because you are subscribed to the Google
Groups "Clojure" g
On Fri, Feb 14, 2014 at 9:41 PM, Mars0i wrote:
> Could someone clarify for me why "some?" as a name for not nil makes sense
> at all in the first place? Not criticizing. I just don't understand what
> existence or there being some of something has to do with nil.
>
nil is often used to indicat
Could someone clarify for me why "some?" as a name for not nil makes sense
at all in the first place? Not criticizing. I just don't understand what
existence or there being some of something has to do with nil.
Maybe I don't understand the intent of nil. I came to Clojure from Common
Lisp.
Likely discussed in #clojure IRC and I checked with some Clojure/core folks
for feedback.
David
On Fri, Feb 14, 2014 at 10:54 PM, Joel Holdbrooks wrote:
> Right. I won't disagree with the function being critical or with avoiding
> breakage. I'm just mostly whining here cause I missed the boat.
exists? is a pretty critical feature for application writers and I asked
several users about it before committing to a name. Unless Clojure decides
to adopt it, little incentive to cause unnecessary breakage.
David
On Fri, Feb 14, 2014 at 10:28 PM, Joel Holdbrooks wrote:
> Slightly off topic, b
As an addendum to my last comment, *not-nil?* would also be a good
candidate. That really doesn't leave room for doubt.
This:
(some? false) ;; => true
Would confuse me. On the other hand this:
(not-nil? false) ;; => true
Would not.
There's really no need to complicate the naming story
On Feb 14, 2014, at 17:25 , Alex Miller wrote:
> The names of these functions were chosen by Rich. There was already some name
> overloading of "some" even before these new functions with some (truthy) and
> some->/some->> (not nil). The new functions keep with the latter meaning.
> Many other
On Friday, February 14, 2014 2:27:49 PM UTC-6, DomKM wrote:
>
> Great changes! I have a question about #5.
>
>
>> 5) New "some" operations
>> Many conditional functions rely on logical truth (where "falsey"
>> values are nil or false). Sometimes it is useful to have functions
>> that rely on "
Hey Howard,
Same story as always - when we moved into the 1.6 release train, we
basically stopped putting new tickets into work so that we could stabilize
the release. That process has taken longer than I expected.
My expectation is that:
1) All of you will try out 1.6.0-beta1 as soon as poss
Also I think the ship on overloading some already sailed with some-> and
some->>
David
On Fri, Feb 14, 2014 at 3:27 PM, Dom Kiva-Meyer wrote:
> Great changes! I have a question about #5.
>
>
>> 5) New "some" operations
>> Many conditional functions rely on logical truth (where "falsey"
>> valu
I would also like to point out that `if-some` reads like it would work
like `if-not` rather than like `if-let`.
Same applies obviously to `when-some` too.
Timothy Baldridge writes:
> +1 to everything Dom Kiva-Meyer said.
>
>
>
> On Fri, Feb 14, 2014 at 2:13 PM, Andrey Antukh wrote:
>
>> Awesom
Dom Kiva-Meyer writes:
>> 5) New "some" operations
>> Many conditional functions rely on logical truth (where "falsey"
>> values are nil or false). Sometimes it is useful to have functions
>> that rely on "not nilness" instead. These functions have been added to
>> support these cases [CLJ-1343]:
exists? doesn't seem right to me. Also we do use `exists?` currently in
ClojureScript since feature detection is so common in client side code and
the name seems more appropriate to me in that context. That could of course
change but we would need to coordinate.
David
On Fri, Feb 14, 2014 at 3:2
+1 to everything Dom Kiva-Meyer said.
On Fri, Feb 14, 2014 at 2:13 PM, Andrey Antukh wrote:
> Awesome! Thanks!
>
>
> 2014-02-14 21:47 GMT+01:00 Daniel :
>
> Thanks to everyone involved!
>>
>>
>> On Friday, February 14, 2014 1:04:09 PM UTC-6, Alex Miller wrote:
>>>
>>> Clojure 1.6.0-beta1 is no
Awesome! Thanks!
2014-02-14 21:47 GMT+01:00 Daniel :
> Thanks to everyone involved!
>
>
> On Friday, February 14, 2014 1:04:09 PM UTC-6, Alex Miller wrote:
>>
>> Clojure 1.6.0-beta1 is now available.
>>
>> Try it via
>> - Download: http://central.maven.org/maven2/org/clojure/
>> clojure/1.6.0-be
>
> Looking forward to this ... any ideas on submitted issues w/ valid patches
> that are in limbo? (*)
>
(*) No good deed, such as this beta release announcement, goes unpunished.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this
Great changes! I have a question about #5.
> 5) New "some" operations
> Many conditional functions rely on logical truth (where "falsey"
> values are nil or false). Sometimes it is useful to have functions
> that rely on "not nilness" instead. These functions have been added to
> support these ca
Clojure 1.6.0-beta1 is now available.
Try it via
- Download: http://central.maven.org/maven2/org/clojure/clojure/1.6.0-beta1
- Leiningen: [org.clojure/clojure "1.6.0-beta1"]
Highlights below or see the full change log here:
https://github.com/clojure/clojure/blob/master/changes.md
We expect Cloj
34 matches
Mail list logo
