[ANN] Clojure 1.9.0-alpha9

[Alex Miller]

Clojure 1.9.0-alpha9 is now available.

Try it via

- Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.9.0-alpha9

- Leiningen: [org.clojure/clojure "1.9.0-alpha9"]

1.9.0-alpha9 includes the following changes since 1.9.0-alpha8:

- NEW clojure.spec/assert - a facility for adding spec assertions to your code. See the docs for *compile-asserts* and assert for more details.

- clojure.spec/merge - now merges rather than flows in conform/unform

- clojure.spec.test/instrument now reports the caller that caused an :args spec failure and ignores spec'ed macros

- clojure.spec.test - `test`, `test-fn`, `testable-syms` renamed to `check`, `check-fn`, and `checkable-syms` to better reflect their purpose. Additionally, some of the return value structure of `check` has been further improved.

- clojure.core/Throwable->map formerly returned StackTraceElements which were later handled by the printer. Now the StackTraceElements are converted to data such that the return value is pure Clojure data, as intended.

[Sam Estep]

Awesome, thank you Alex! By the way, are there any plans to add more elegant support for "hybrid maps" (as discussed here and here) in the future?

[Alex Miller]

Haven't talked about it yet.

[Leon Grapenthin]

Small bug report

Throwable->map in core_print.clj doesn't handle Throwable.getCause returning null in L463. This results in a NPE in StrackTraceElement->vec in the same file in some cases, so printing a stacktrace results in a new Exception which is a bit confusing.

[Leon Grapenthin]

Another small bug report:

(let [{:keys [a/b] :or {a/b 42}} {}]

  b)

Evaluates to nil, but should evaluate to 42

(let [{:keys [a/b] :or {b 42}} {}]

   b)

Evaluates to 42, but should evaluate to nil.

On Tuesday, July 5, 2016 at 9:50:47 PM UTC+2, Alex Miller wrote:

[Alex Miller]

This is the correct behavior. The :or map keys are always the local names being bound (not the keys being looked up in the map).

[Alex Miller]

Thanks! If I could trouble you to make a jira for that, would love to get it fixed.

[Leon Grapenthin]

@Alex Miller: Please reconsider. What you state does not apply to 1.8, i. e. the ns is required in :or and such code is broken in 1.9

1.8/1.9 differences:

(let [{:keys [a/b] :or {b 42}} {}] 

  b)

=>

1.8: nil

1.9: 42(let [{:keys [a/b] :or {a/b 42}} {}] 

  b)

=>

1.8: 42

1.9: nil

[Nicola Mometto]

I'd say that's a bug with 1.8 rather than 1.9

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

[Alex Miller]

This *is* different than 1.8 (and prior) because it has been buggy since namespaced keys were added (due to a lack of tests - entirely my fault). Nothing was ever documented about this behavior - it was purely accidental and I would consider it in the realm of "unspecified".

In 1.9 I added additional tests and tightened up this code in the process of adding the namespaced key support.

[Leon Grapenthin]

1.9 could still support the behavior that worked in 1.8 and in CLJS, too, or throw a compile time Exception. 

If we had known this change in behavior, fixing it in the codebase wouldn't have been much trouble. But a missing default can lead to errors far away so it takes time to get to the ground of this.

If there was no (working) other way to provide a default for namespaced keys in 1.8 I believe that many people will have tried adding the ns and ran with it.

[Alex Miller]

There will soon be a spec for let that will fail in this circumstance, letting you know.