[ANN] Clojure 1.6.0-beta1

2,891 views
Skip to first unread message

Alex Miller

unread,
Feb 14, 2014, 2:04:09 PM2/14/14
to clo...@googlegroups.com
Clojure 1.6.0-beta1 is now available. 
 
Try it via 
- Leiningen: [org.clojure/clojure "1.6.0-beta1"]

Highlights below or see the full change log here:

We expect Clojure 1.6.0-beta1 to be close to a release candidate; no other big changes are planned. Please give us your feedback and final issues if you find them so we can do the final release!

Clojure 1.6.0-beta1 has the following changes from 1.5.1:

1) Clojure now builds with Java SE 1.6 and emits bytecode requiring Java
SE 1.6 instead of Java SE 1.5. [CLJ-1268]

2) The following features are no longer marked "Alpha" in Clojure:

* Watches - add-watch, remove-watch  
* Transients - transient, persistent!, conj!, assoc!, dissoc!, pop!, disj!
* Exception data - ex-info, ex-data
* Promises - promise, deliver
* Records - defrecord
* Types - deftype
* Pretty-print tables - print-table

3) The clojure.java.api package provides a minimal interface to bootstrap
Clojure access from other JVM languages. Example:

    IFn map = Clojure.var("clojure.core", "map");
    IFn inc = Clojure.var("clojure.core", "inc");
    map.invoke(inc, Clojure.read("[1 2 3]"));

4) Map destructuring extended to support namespaced keys. [CLJ-1318]

In the past, map destructuring with :keys and :syms would not work
with maps containing namespaced keys or symbols. The :keys and :syms
forms have been updated to allow them to match namespaced keys and
bind to a local variable based on the name.

Examples:

    (let [m {:x/a 1, :y/b 2}
          {:keys [x/a y/b]} m]
      (+ a b))

    (let [m {'x/a 1, 'y/b 2}
          {:syms [x/a y/b]} m]
      (+ a b))

Additionally, the :keys form can now take keywords instead of symbols.
This provides support specifically for auto-resolved keywords:

    (let [m {::x 1}
          {:keys [::x]} m]
      x)

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

* some? - same as (not (nil? x))
* if-some - like if-let, but checks (not (nil? test)) instead of test
* when-some - like when-let, but checks (not (nil? test)) instead of test

6) Hashing overhaul 

The Clojure hash algorithms have changed for many primitives and collections.
Read the changelog and http://clojure.org/data_structures#hash for more detail
and if you are building external collections. 

In general, this change creates better hash codes (better bit dispersion, fewer
collisions) to improve performance of hashed collections (maps and sets). 
NOTE: One side effect may be that code currently relying on the arbitrary order
of hashed elements in a collection (tests for example) may need to be fixed.

7) Other new things

* unsigned-bit-shift-right - Java's >>> 
* clojure.test/test-vars - run a set of tests with fixtures

8) Printing enhancements

  Print metadata for functions when *print-meta* is true and remove errant space at beginning.
  pprint cl-format now supports E, F, and G formats for ratios.

9) Error messages 

  Print type information in reflection messages to help diagnose problem. 
  If non-seq passed where seq is needed, error message now is an ExceptionInfo with the instance value, retrievable via ex-data.
  Fix error message reporting for "munged" function names (like a->b).
  Handle more cases and improve error message for errors in defprotocol definitions.
  Better handling of exceptions with empty stack traces.
  Exceptions thrown in the top level ns form are reported without file or line number.

10) Documentation strings

  Fix typos in clojure.instant/validated and other internal instant functions.
  Correct doc string for ns macro.
  Clarify value of *file* is undefined in the REPL.
  Fix a number of spelling errors in namespace and doc strings.
  Update defmulti doc to clarify expectations for hierarchy argument.
  Fix minor typos in documentation and comments
  Mention that keys and vals order are consistent with seq order

11) Performance

  Improve speed of STM by removing System.currentTimeMillis.
  clojure.java.io/do-copy: use java.nio for Files
  Reduce overhead of protocol callsites by removing unneeded generated
  cache fields.

12) Other enhancements

  Make *default-data-reader-fn* set!-able in REPL, similar to *data-readers*.
  Make clojure.inspector/inspect-tree work on sets.
  Make browse-url aware of xdg-open.
  Fix clojure.core.reducers/mapcat does not stop on reduced? values.
  -> and ->> have been rewritten to work with a broader set of macros.
  clojure.walk now supports records.
  Removed all unnecessary cases of sneakyThrow.
  Allow EdnReader to read foo// (matches LispReader behavior).
  Remove uses of _ as a var in the Java code (causes warning in Java 8).
  Add record? predicate.
  ArraySeq dead code cleanup, ArraySeq_short support added.
  Primitive vectors should implement hasheq and use new hash algorithm

13) Bug Fixes

  Make range consistently return () with a step of 0.
  Make interleave return () on 0 args and identity on 1 args.
  Update internal usages of the old metadata reader syntax to new syntax.
  Make bigint and biginteger functions work on double values outside long range.
  Make Compile.java flush but not close stdout so errors can be reported.
  Remove bad version.properties from sources jar.
  Fix invalid behavior of Delay/deref if an exception is thrown - exception will
  now be rethrown on subsequent calls and not enter a corrupted state.
  Fix several issues with instance? to make it consistent when used with apply.
  Protocol fns with dashes may get incorrectly compiled into field accesses.
  Add check to emit invokePrim with return type of double or long if type-hinted.
  clojure.java.io URL to File coercion corrupts path containing UTF-8 characters.
  Accept whitespace in Record and Type reader forms (similar to data literals).
  Allow ** as a valid symbol name without triggering dynamic warnings.
  Add support to clojure.reflect for classes with annotations.
  Evaling #{do ...} or [do ...] is treated as do special form.
  Indirect function calls through Var instances fail to clear locals.
  pprint tests fail on Windows, expecting \n.
  Make into-array work consistently with short-array and byte-array on
  bigger types.
  Data structure invariants are violated after persistent operations when
  collision node created by transients.
  Multiplication overflow issues around Long/MIN_VALUE
  Inconsistent numeric comparison semantics between BigDecimals and other numerics
  Clojure can leak memory in a servlet container when using dynamic
  bindings or STM transactions.
  Subvecs of primitve vectors cannot be reduced
  Case expressions use a mixture of hashCode and hasheq, potentially
  leading to missed case matches when these differ.
  proxy-super does not restore original binding if call throws exception
  clojure.repl/source errors when *read-eval* bound to :unknown
  clojure.string/trim uses different definition of whitespace than
  triml and trimr
  StackOverflowError on exception in reducef for PersistentHashMap
  fold
  Fix some tests in the Clojure test suite to make their names unique
  and independent of hashing order
  Empty primitive vectors throw NPE on .equals with non-vector
  sequential types

Happy Valentine's Day!

Alex Miller

Alan Malloy

unread,
Feb 14, 2014, 2:32:44 PM2/14/14
to clo...@googlegroups.com
This is awesome! Thanks Alex, and everyone else responsible for this release.

You have a small mistake in this summary: two different issues are both called CLJ-935, and two issues that are probably different are both called CLJ-1328.

Alex Miller

unread,
Feb 14, 2014, 3:14:14 PM2/14/14
to clo...@googlegroups.com
Thanks, we'll do another update to the changes file before final release and I'll try to get those cleaned up.

Dom Kiva-Meyer

unread,
Feb 14, 2014, 3:27:49 PM2/14/14
to clo...@googlegroups.com
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 cases [CLJ-1343]:
* some? - same as (not (nil? x))
* if-some - like if-let, but checks (not (nil? test)) instead of test
* when-some - like when-let, but checks (not (nil? test)) instead of test

It seems inconsistent to have "some" mean two very different things within the same namespace, especially since the prior uses of "some" (`some`, `some-fn`, etc.) are more in keeping with its primary definition of having to do with amount (and operate on seqs or variadic arguments) while the new functions have to do with existence (and operate on any single value). Why not call these new functions `not-nil?`, `if-not-nil`, and `when-not-nil`? Or, if "not-nil" is too unwieldy then what about "exists" (`exists?`, `if-exists`, `when-exists`)?

Are these names up for discussion?

Cheers,
Dom


--
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/groups/opt_out.

Howard M. Lewis Ship

unread,
Feb 14, 2014, 3:30:21 PM2/14/14
to clo...@googlegroups.com
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. 

Howard M. Lewis Ship

unread,
Feb 14, 2014, 3:33:27 PM2/14/14
to clo...@googlegroups.com
Good points!  If some did not exist, then it would be a good name, but this does feel a bit sloppy, and exists isn't used in clojure.core yet, but still captures the intent without conflict.

Daniel

unread,
Feb 14, 2014, 3:47:41 PM2/14/14
to clo...@googlegroups.com
Thanks to everyone involved!

Andrey Antukh

unread,
Feb 14, 2014, 4:13:22 PM2/14/14
to clo...@googlegroups.com
Awesome! Thanks!


--
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/groups/opt_out.



--

Timothy Baldridge

unread,
Feb 14, 2014, 5:30:16 PM2/14/14
to clo...@googlegroups.com
+1 to everything Dom Kiva-Meyer said. 

“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)

David Nolen

unread,
Feb 14, 2014, 5:36:51 PM2/14/14
to clojure
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

Tassilo Horn

unread,
Feb 14, 2014, 5:43:13 PM2/14/14
to Dom Kiva-Meyer, clo...@googlegroups.com
Dom Kiva-Meyer <li...@domkm.com> 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]:
>> * some? - same as (not (nil? x))
>> * if-some - like if-let, but checks (not (nil? test)) instead of test
>> * when-some - like when-let, but checks (not (nil? test)) instead of test
>
> It seems inconsistent to have "some" mean two very different things
> within the same namespace,

I agree.

> Why not call these new functions `not-nil?`, `if-not-nil`, and
> `when-not-nil`? Or, if "not-nil" is too unwieldy then what about
> "exists" (`exists?`, `if-exists`, `when-exists`)?

Or:

non-nil?, if-non-nil, when-non-nil
nonnil?, if-nonnil, when-nonnil
nnil?, if-nnil, when-nnil

> Are these names up for discussion?

I had the same feeling and commented on the issue in JIRA before the
patch was applied.

http://dev.clojure.org/jira/browse/CLJ-1343

But neither Rich nor Alex replied when they looked over the issue
afterwards, so I guess they like those names. (This could become the
new "contains?")

Bye,
Tassilo

Nicola Mometto

unread,
Feb 14, 2014, 6:01:59 PM2/14/14
to clo...@googlegroups.com

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.
>>>> *NOTE:* One side effect may be that code currently relying on the
>> http://www.niwi.be <http://www.niwi.be/page/about/>

David Nolen

unread,
Feb 14, 2014, 6:04:26 PM2/14/14
to clojure
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 <li...@domkm.com> wrote:

Alex Miller

unread,
Feb 14, 2014, 6:21:40 PM2/14/14
to clo...@googlegroups.com
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 possible and report any issues (we've got one on the test-vars change already reported).
2) Whatever issues are reported get resolved ASAP.
3) We publish 1.6.0.
4) Rich looks at the Triaged tickets (where we've backed up the pipeline) and approves a batch for 1.7 which can start flowing again. As that gets moving, I will continue reviewing pending tickets to bring new changes in.

My hope is that this is a couple weeks, but depends on #1.

The set of pending tickets is prioritized based on:
- defects over enhancements 
- high severity over low severity
- more votes over less votes - voting is how the community can indicate what is important. You do not need a CA to join JIRA or vote on tickets.
- patch over suggested approach over neither 
- etc

Alex Miller

unread,
Feb 14, 2014, 6:25:36 PM2/14/14
to clo...@googlegroups.com


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 "not nilness" instead. These functions have been added to
support these cases [CLJ-1343]:
* some? - same as (not (nil? x))
* if-some - like if-let, but checks (not (nil? test)) instead of test
* when-some - like when-let, but checks (not (nil? test)) instead of test

It seems inconsistent to have "some" mean two very different things within the same namespace, especially since the prior uses of "some" (`some`, `some-fn`, etc.) are more in keeping with its primary definition of having to do with amount (and operate on seqs or variadic arguments) while the new functions have to do with existence (and operate on any single value). Why not call these new functions `not-nil?`, `if-not-nil`, and `when-not-nil`? Or, if "not-nil" is too unwieldy then what about "exists" (`exists?`, `if-exists`, `when-exists`)?

Are these names up for discussion?

Hey Dom et al,

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 names were considered, including everything I've seen someone mention (-not-nil, exists, nnil, etc). As far as I know these names are final, however, I will relay all of the feedback I've seen here, on #clojure, and on Twitter to Rich for consideration.

Alex
 

Michael Gardner

unread,
Feb 14, 2014, 6:48:51 PM2/14/14
to clo...@googlegroups.com
On Feb 14, 2014, at 17:25 , Alex Miller <al...@puredanger.com> 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 names were considered, including everything I've seen someone mention (-not-nil, exists, nnil, etc). As far as I know these names are final, however, I will relay all of the feedback I've seen here, on #clojure, and on Twitter to Rich for consideration.

Probably way too late for this, but if there are truthy and non-nil versions of multiple functions/macros then it would be good to use a consistent suffix to indicate those semantics, e.g. if/if*, when-let/when-let*, etc (asterisk just used as an example).

Joel Holdbrooks

unread,
Feb 14, 2014, 9:52:56 PM2/14/14
to clo...@googlegroups.com
Why not just call it truthy? and have a complementary function called falsey?? It seems to me that would easily resolve the naming issue here because, as was described, this is what the function does. To me, and it would seem others, some? does not clearly communicate the nature of the predicate.

Joel Holdbrooks

unread,
Feb 14, 2014, 10:12:21 PM2/14/14
to clo...@googlegroups.com
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 here. It's also easy to remember!

Joel Holdbrooks

unread,
Feb 14, 2014, 10:28:01 PM2/14/14
to clo...@googlegroups.com
Slightly off topic, but I wish I would have been apart of that discussion because there's another example of function that, at face value, doesn't clearly express it's nature. In tandem with my comment below, there should really be a little more consideration for the names of these functions. I would agree that short function names should be favored but not at the expense of communication.

There's probably nothing that can be done for this now, but while feature detection is common in a program, it is uncommon throughout a program. I would thus argue, that a name with a higher degree of precision, and perhaps more characters, would have been a better choice.

David Nolen

unread,
Feb 14, 2014, 10:46:23 PM2/14/14
to clojure
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

Joel Holdbrooks

unread,
Feb 14, 2014, 10:54:55 PM2/14/14
to clo...@googlegroups.com
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. :-)

Did that discussion take place here or in Jira? I'd definitely like to be able to chime in with thoughts/suggestions in the future WRT this topic.

David Nolen

unread,
Feb 14, 2014, 11:48:47 PM2/14/14
to clojure
Likely discussed in #clojure IRC and I checked with some Clojure/core folks for feedback.

David

Mars0i

unread,
Feb 15, 2014, 12:41:52 AM2/15/14
to clo...@googlegroups.com
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.  nil is a weird beast in CL, but it's also a weird beast in Clojure.

Is the idea that nil is supposed to be an empty structure, and empty? and seq are too general?  But unlike nil in Common Lisp, nil in Clojure is not an empty structure, even though (empty? nil) is true.  [], (), (lazy-seq), #{}, and {} are empty structures.  Am I misunderstanding?

Mark Engelberg

unread,
Feb 15, 2014, 1:25:22 AM2/15/14
to clojure
On Fri, Feb 14, 2014 at 9:41 PM, Mars0i <mars...@logical.net> 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 indicate that a value is not present.
For example:
(get {:a 1 :b 2} :c) -> nil
nil is also returned by seq to indicate that the collection is empty and therefore doesn't have a first and rest.
So I think the reasoning is that you are asking if the result is "something" versus "nothing".  In other words, some? is essentially a short-form of the name "something?".

Coming to Clojure from Scheme, I've always thought it quirky that Clojure has two distinct falsey values, false and nil.  I remember a thread in the early days of Clojure in which it was explained to me that this was a common idiom in Common Lisp, and was included in Clojure primarily to enable the pattern:
(when (seq s) ...)

It also enabled a lot of idioms that *almost* work, but can bite you if you're not careful, for example (filter identity ...) to strip out nil values (but oops, you didn't mean for it to also strip out false values).  These sorts of things are a fairly common source of bugs, because it can often be hard to reason about whether you care about a value being truthy, falsey, not false, false, not nil, or nil, and determine exactly what promises are made by library predicates you are using.  So what we see now is the proliferation of variations on the core constructs that care specifically about non-nil values rather than truthy values, because it turns out that in a lot of cases you really just want to get rid of or detect nil values but not false.  This trend started with keep and keep-indexed, then grew to some-> and some->>, and now the newest additions.

I agree that it is very confusing that "some" searches for the first truthy value, but some-> and some->> only care about non-nil values.  The new names are clearly modeled after the some-> and some->> functions, but that just makes the behavior of the original "some" even more of a glaring outlier.

tcrayford

unread,
Feb 15, 2014, 2:00:03 AM2/15/14
to clo...@googlegroups.com
I ran clojure 1.6 through a benchmark suite (proprietary, but thought knowing about results might be interesting). Most of the benches were 1-2ms slower, but one (that involves pushing around 10k clj-tuples into a set) went from ~90ms to ~4ms. I'd guess that's the new hash stuff coming in, but either way, that speedup is super awesome!

Alex Miller

unread,
Feb 15, 2014, 8:30:22 AM2/15/14
to clo...@googlegroups.com
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.

Alex Miller

unread,
Feb 15, 2014, 8:35:12 AM2/15/14
to clo...@googlegroups.com
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 lot of async examples out there that incorrectly use if-let and when-let for this.

Andy-

unread,
Feb 15, 2014, 8:35:23 AM2/15/14
to clo...@googlegroups.com
inline
I *think* the idea to name it *some* is since nil often means "no value" (as already said by puzzler). This is also how Scala and F# name it:

And the (some-> ..) macro has existed for a while which works the same so I think it makes a lot of sense to call it some? instead of non-nil?.

HTH
Message has been deleted
Message has been deleted

Mars0i

unread,
Feb 15, 2014, 4:01:34 PM2/15/14
to clo...@googlegroups.com
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 some->, some->>, some?).

I celebrate the semi-arbitrary quirkiness of function names in Common Lisp, but that's kind of perverse.  I celebrate more, and benefit from the rational systematicity of function names in Clojure.  I guess wouldn't be bothered by the two "some" concepts in Clojure if the language hadn't already exhibited such a high standard for function choices and names.  I am fairly new to Clojure, but the elegant design and naming is obviously a great part of the appeal of the language.  I have great respect for people who have been working with Clojure for a long time, and especially those who have designed and built the language, but "some" surprises me.

I understand that we don't want to break code that already uses the existing functions with "some" in their names, and there is a lot of code to break at this point.  But is there a possibility of providing new names and deprecating old ones for the sake of long term improvement?  In 1.5, there are two functions each with the two meanings.  Adding more functions without fixing the issue has the potential to exacerbate the problem by making it harder to abandon one use or the other of "some".  If adding to the not-nil family of "some" functions is preferable, maybe some and some-fn could be deprecated in favor of alternative names for the same functions.  Maybe that's too difficult at this point, though.

(I keep thinking of something I once read by Bjarne Stroustrup suggesting that when he first introduced C++, his goal was to keep it simple and elegant.  I'm not seriously worried that Clojure will become a ... monstrosity (I say that affectionately) like Common Lisp, though.)

Alex Miller

unread,
Feb 15, 2014, 4:02:35 PM2/15/14
to clo...@googlegroups.com
truthy? = identity
falsey? = not

Joel Hodbrooks

unread,
Feb 15, 2014, 4:04:13 PM2/15/14
to clo...@googlegroups.com
That’s fair.

On February 15, 2014 at 1:02:43 PM, Alex Miller (al...@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 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 a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/tseJgAi3HC4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

Joel Hodbrooks

unread,
Feb 15, 2014, 4:19:23 PM2/15/14
to clo...@googlegroups.com
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 (al...@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 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 a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/tseJgAi3HC4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

Andy Fingerhut

unread,
Feb 15, 2014, 5:32:21 PM2/15/14
to clo...@googlegroups.com
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 for the 1-2ms slower, I am curious to know what percentage increase that represents over Clojure 1.5.1?

I have some benchmark results on the wiki page below.  Look especially in the column "Clojure 1.6.0 just after this commit on Jan 30 2014" near the bottom of the table for some speed comparisons versus the first column labeled "Using Clojure 1.6.0-alpha3 hash (same as Clojure 1.5.1)".

    http://dev.clojure.org/display/design/Better+hashing

Andy


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

Alex Baranosky

unread,
Feb 15, 2014, 5:48:12 PM2/15/14
to clo...@googlegroups.com
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.

Эльдар Габдуллин

unread,
Feb 16, 2014, 1:54:12 AM2/16/14
to clo...@googlegroups.com
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 написал:

Alex Walker

unread,
Feb 16, 2014, 12:29:38 PM2/16/14
to clo...@googlegroups.com
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? variants, I'd suggest a positive that I found strangely available:

exists?
if-exists[?]
when-exists[?]

Or, more proper, though potentially more overloaded: value?, if-value[?], when-value[?].

Mars0i

unread,
Feb 16, 2014, 9:54:49 PM2/16/14
to clo...@googlegroups.com
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 quantifiers in logic, as in "Some x is F",  "There exists an x such that Fx".  The clojure function every? plays the role of the universal quantifier (All x are F), and the some function plays the role of the existential quantifier, although it does more.

However, a function named "something?" doesn't really sound like an existential quantifier (despite the fact that in English "something" can be used to express the existential quantifier ("something is F").  Rather, "something?" suggests that there's something, rather than nothing, i.e. rather than nil.

(something? false) => false
is still a little bit confusing, but if you think of it as saying that falsehood is not nothing, then maybe it makes sense.

Herwig Hochleitner

unread,
Feb 17, 2014, 10:54:36 AM2/17/14
to clo...@googlegroups.com
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 it supposed to stay that way?

There is a long standing ticket for that, which seems to have been overlooked when promoting transients out of alpha: http://dev.clojure.org/jira/browse/CLJ-700


--

Alex Miller

unread,
Feb 17, 2014, 11:16:48 AM2/17/14
to clo...@googlegroups.com
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 (due to refactoring of key interfaces, etc). I would expect it to be looked at for the next release.

Alex

Alex Miller

unread,
Feb 18, 2014, 12:40:25 PM2/18/14
to clo...@googlegroups.com
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 binding nature

Regarding 1 and 2, all of these factors were discussed prior to selecting the current names, so I don't think there was any new compelling information. All of these names (including the ones chosen) have downsides (double negatives, possible collisions with existing non-core code, etc). The current names will remain as is.

Regarding 3, "let" was omitted in the name due to length but we are going to tweak the docstring to signal more strongly the relationship to if-let and when-let.

Alex
Reply all
Reply to author
Forward
0 new messages