[ANN] Clojure 1.9.0-alpha6

[Alex Miller]

Clojure 1.9.0-alpha6 is now available.

Try it via

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

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

1.9.0-alpha6 includes the following changes since 1.9.0-alpha5:

- & regex op now fails fast when regex passes but preds do not

- returns from alt/or are now map entries (supporting key/val) rather than 2-element vector

- [BREAKING] fn-specs was renamed to fn-spec and returns either the registered fspec or nil

- fspec now accepts ifn?, not fn?

- fspec impl supports keyword lookup of its :args, :ret, and :fn specs

- fix fspec describe which was missing keys and improve describe of :args/ret/fn specs

- instrument now checks *only* the :args spec of a var - use the clojure.spec.test functions to test :ret and :fn specs

- Added generator support for bytes? and uri? which were accidentally left out in alpha5

[adrian...@mail.yu.edu]

I was wondering if you could shed some light on why instrument was changed to not automatically check the :ret and :fn specs. I miss that feature already, hehe, although I understand that these are alpha versions and things evolve. :) I just want to understand the context behind this decision. If I missed relevant discussion already explaining this, I apologize. 

[Alex Miller]

Check out the thread at https://groups.google.com/forum/m/#!topic/clojure/RLQBFJ0vGG4

--
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/JIgmEFhAlq8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sean Corfield]

Hopefully you can also provide an answer around my question (in that thread) about losing the “nice” exceptions and instead getting “just” a data structure from things like check-var?

 

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

[adrian...@mail.yu.edu]

Thanks for the link Alex. I understand what changed, but I still don't understand why. Could you elaborate on the thought that went into this? Thank you. 

[Alex Miller]

Instrumentation is about verifying that code is invoked correctly (things *external* to a function).

The :ret and :fn specs verify that things *internal* to a function are working correctly, and that is seen as a testing-time activity with support in clojure.spec.test.

[mattias w]

Please make stest/instrument check :ret too, not only :args.

I have been experimenting a lot with spec during December, and I really like it. On the downside, the syntax is very verbose, compared to prismatic schema. However, reuse is much simpler than for schemas.

I disagree with this decision from two different reasons:

1. "that code is invoked correctly", yes, it is an API, but common courtesy also requires us to make sure we return the expected result, i.e. check the :ret

2. Performance is not a problem for checking :ret, since as cheap as checking a single args, i.e. will not increase execution time a lot.

Without checking the results, the s/fdef is really use-less.

A compromise would be to have a simple option to (stest/instrument) to make it also include run :ret.

For now, I a made a copy of the original definitions of instrument, instrument-1 and spec-checking-fn, and override the default ones.

---

I would recommend everyone interested in property based testing to go beyond stest/check, since in most cases doesn't find more problems than ML-like type-checking would have done. Property based testing is something completely different, I have done some in Erlang. There are a lot of good samples and concepts for Erlang. Just google "quickcheck erlang" "quickcheck elixir". There is also a lot of good articles by John Hughes and his collegues at https://www.researchgate.net/ and many recordings like https://www.youtube.com/watch?v=H18vxq-VsCk

---