[ANN] Clojure 1.9.0-alpha9

536 views
Skip to first unread message

Alex Miller

unread,
Jul 5, 2016, 3:50:47 PM7/5/16
to Clojure
Clojure 1.9.0-alpha9 is now available.

Try it via

- 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

unread,
Jul 5, 2016, 4:07:27 PM7/5/16
to Clojure
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

unread,
Jul 5, 2016, 4:18:16 PM7/5/16
to Clojure
Haven't talked about it yet.

Leon Grapenthin

unread,
Jul 6, 2016, 5:09:59 AM7/6/16
to Clojure
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

unread,
Jul 6, 2016, 5:40:58 AM7/6/16
to Clojure
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

unread,
Jul 6, 2016, 7:43:46 AM7/6/16
to clo...@googlegroups.com
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

unread,
Jul 6, 2016, 7:46:33 AM7/6/16
to clo...@googlegroups.com
Thanks! If I could trouble you to make a jira for that, would love to get it fixed.

Leon Grapenthin

unread,
Jul 6, 2016, 8:01:52 AM7/6/16
to Clojure
@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

unread,
Jul 6, 2016, 8:03:21 AM7/6/16
to clo...@googlegroups.com
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.

signature.asc

Alex Miller

unread,
Jul 6, 2016, 8:17:14 AM7/6/16
to Clojure
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

unread,
Jul 6, 2016, 8:42:22 AM7/6/16
to Clojure
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

unread,
Jul 6, 2016, 8:59:41 AM7/6/16
to Clojure
There will soon be a spec for let that will fail in this circumstance, letting you know.
Reply all
Reply to author
Forward
0 new messages