Support for Clojure 1.8

[daslu]

Continuing a recent discussion at Clojurians Slack, I have had some experiments porting Meander to Clojure 1.8.

The following changes were necessary:

• Changing the Clojure dependency to "1.8.0"
• Adding clojure-future-spec as a dependency
• Adding a patch namespace with all the necessary predicates (nat-int?, etc.), that were added at Clojure 1.9.
• Changing ##Inf with Double/POSITIVE_INFINITY.

So far, all Clojure JVM tests pass, except for

• seq-zero-or-more-nested-mvr, vec-zero-or-more-nested-mvr, that rely on spec working with some Clojure 1.9 predicate (simple-symbol).
• rp+-test, that seems to have a typo causes an error at Clojure 1.8.
  
  Clojurescript may need some more work.

If we want to maintain a version that supports Clojure 1.8, let us discuss:

• Does it have to be a separate code base?
• If so, what would be the appropriate namespacing convention.

Maybe it is better to come back to these questions after some experimentation, and after we hopefully understand if there are any differences in functionality.

I will keep experimenting with Meander at Clojure 1.8. For now, just wanted to document the details here.

[noprompt]

I'm not sure if a separate code base would be needed. It seems like it should be possible to support 1.8 by fixing some of the above issues. The fix with ##Inf, missing functions, etc. seem trivial to fix.

We could add a separate test profile for 1.8 which depends on clojure-future-spec which would be run via the bin/test script. Adding clojure-future-spec as an explicit dependency does not seem necessary since the library consumer could bring that dependency in themselves.

[daslu]

Thanks.

An explicit clojure-future-spec seems necessary, since Meander itself relies on spec (e.g., s/fdef at various places).

Still haven't manage to make the Clojurescript part work with the Clojure 1.8 patch. I will dive into that a little later.

[noprompt]

Interesting. For some reason I thought it wouldn't be needed since, if the library consumer was providing those namespaces by way of clojure-future-spec, those namespaces would be on the class path and resolve properly. I think it is possible to put the burden on the end user to provide those namespaces. I suppose I should try it out locally and see for myself! 😄

[noprompt]

We could also place the specs in their own namespace(s).

[noprompt]

Dusting this off. Specs have since been placed in their own namespace. To close this issue

• ##Inf needs to be replaced. A macro, call it (Inf), could do this and properly target JVM/JS.
• Missing functions need to be installed, probably in the runtime namespaces.

I'm leaving this ticket open for anyone in the community who would like to take it.