[ANN] clojure-future-spec, a backport of clojure.spec for 1.8

[Nikita Prokopov]

Hi!

Not sure if a good idea or bad, but if you were eager to play with latest version of clojure.spec but don’t want to upgrade your production to alpha version of the language, you can add clojure.spec capabilities as a library to 1.8:

https://github.com/tonsky/clojure-future-spec

:dependencies [

  [org.clojure/clojure "1.8.0"]

  [clojure-future-spec "1.9.0-alpha8"]

]

(require '[clojure.spec :as spec])

(require '[clojure.spec.gen :as spec.gen])

(require '[clojure.future :refer :all])

clojure.future namespace contains all new clojure.core functions like int?, seqable? etc

The version numbers will follow clojure 1.9 versions. Expect this lib upgraded with every new Clojure alpha release until 1.9 if finally out.

Nikita.

[Sean Corfield]

Interesting idea.

 

If you’re already on Clojure 1.8, I think it’s pretty safe to upgrade to the Alpha builds of 1.9. We’re running 1.9 Alpha 7 in production at the moment (and will move to Alpha 8 in our next build after today).

 

The only glitches we ran into were name collisions in libraries due to new predicates being added to core, and only one of those caused an actual breakage – and those libraries all got updated very quickly (big thanks mostly to Peter Taoussanis for the fast responses).

 

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

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

[Lucas Bradstreet]

This looks great Nikita.

Sean, a lot of library developers still want to support Clojure 1.8,
but this would prevent using spec with their projects. This would help
there. Onyx in particular was going to avoid using spec for the time
being, but we may re-evaluate now.

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

[Sean Corfield]

On 6/29/16, 10:03 AM, "Lucas Bradstreet" <clo...@googlegroups.com on behalf of lucasbr...@gmail.com> wrote:
> Sean, a lot of library developers still want to support Clojure 1.8,
> but this would prevent using spec with their projects.

clojure.java.jdbc solves that by having the specs in a separate namespace (and by the tests conditionally loading that and clojure.spec.test). clojure.java.jdbc supports back to Clojure 1.4.

Nikita, it would be interesting to know how far back (in Clojure versions) your library could support. I can see real value in being able to back port spec beyond 1.8…

[Lucas Bradstreet]

Thanks Sean. You make an excellent point with specs being in a
separate namespace. I had thought that using fdef would have prevented
doing something like this but it appears I am wrong.

[Sam Estep]

I spent quite a while trying to figure out how I can use some features of spec, like destructuring, to work properly when my specs are in a separate namespace. I asked a question about this on Stack Overflow; do you have any advice on how to solve the issues I detailed there?

[se...@corfield.org]

I can’t help but think you’re making it way more complicated than it needs to be.

 

Define ::config in example.spec, and in example.core use :example.spec/config (and, yes, require the example.spec namespace).

 

You need to avoid circular namespace dependencies.

 

Sean Corfield -- (904) 302-SEAN

An Architect's View -- http://corfield.org

[Sam Estep]

Did you read my whole question? It doesn't work to have the implementation namespace require the spec namespace either, as I demonstrated in my second example, where the spec for the factor function uses the prime? predicate.

[Matan Safriel]

Nikita, this is cool, e.g. as lighttable does not yet fully support 1.9. 

Can you say something about how are these backports derived? so that I can get an intuition into how much it is at par with the real thing?

Does it involve a lot of code rewrite to backport each 1.9 alpha version?

[Nikita Prokopov]

Matan,

spec is pretty isolated part of Clojure, so it’s basically a copy-paste job with couple of gaps filled in that were introduced in 1.9.

Updating it is basically getting diff from clojure and applying it to my repo. Sometimes with some manual corrections.

Nikita.

--

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/qZZXSzY7apA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.

[Matan Safriel]

Cool!!

Sent from my mobile

-------- Original Message --------
From:Nikita Prokopov
Sent:Sun, 25 Sep 2016 11:52:19 +0300
To:Clojure
Subject:Re: [ANN] clojure-future-spec, a backport of clojure.spec for 1.8