Fork me on GitHub

@alexmiller it would be better as a s/map-of but afaik I can't use that in a regex


I don't have any explicit keys

Alex Miller (Clojure team)00:10:53

Any registered keys will get checked


that would be bad actually


I'm trying to spec gen/hash-map


come to think of it I can just do (s/* (s/cat :k keyword? :gen gen?))


and that's perfect


So I'm specing some macros


And it seems common for there to be macro args where there's a straightforward spec for the runtime value, but the macrotime form could be almost anything


So my first thought is to use any?, but that's unsatisfying since it doesn't tell users anything and doesn't even try to catch problems evident at macroexpansion time


But anything fancier would be somewhat complex


So I'm wondering if it's worth it


Or if we should just expect macro specs to have a lot of any?s in them


@gfredericks I think your macro specs shouldn't be (can't be?) concerned about runtime semantics

Alex Miller (Clojure team)13:10:44

I’ve spent a fair amount of time looking at this and in general, it’s quite common for :ret to not be worth spec'ing

Alex Miller (Clojure team)13:10:57

and in that you should just omit it

Alex Miller (Clojure team)13:10:31

currently macros are skipped during check and instrument only checks :args, so there is not much value in spec’ing :ret anyways beyond docs

Alex Miller (Clojure team)13:10:39

for :args where some can be scoped but others can’t, I think use of any? is fine (you can see some of this in the specs I’ve done in clojure.core.specs)

Alex Miller (Clojure team)13:10:07

and then consider what you are expanding to - sometimes it’s better to spec that instead (particularly if it bottoms out at a function)


That makes sense; thanks


Is there a suggested approach to building specs in Clojure-1.8 code in anticipation of the 1.9 release? The “alpha” label puts managers off systems that are rapidly going into production, but I would rather be writing specs as I write code, rather than trying to go back to older code and updating it after 1.9 comes out.


i haven't used it, but is the effort i've heard about


@quoll Any chance that you can persuade them that Clojure 1.9 Alpha = Clojure 1.8 + spec?

Alex Miller (Clojure team)16:10:09

not to shoot down a direction towards more spec usage, but that is not exactly true and will become less so

Alex Miller (Clojure team)16:10:35

1.9 is still alpha for good reasons and will not go beta until there are a few more things that have been stabilized. It is still reasonably likely that there will be significant changes in the spec internals.

Alex Miller (Clojure team)16:10:58

most of that would probably not affect the api but it may affect the idea of forms as the information model for specs

Alex Miller (Clojure team)17:10:25

there is a lot of concern that we get certain parts of spec “right” as they will be very difficult to change later

Alex Miller (Clojure team)17:10:45

so if you’re worried about investing in something that might change, then your managers are right and you should hold off :)

Alex Miller (Clojure team)17:10:38

if you’re worried about using alpha software because it may have known and significant bugs, you should also hold off, because there are some :)

Alex Miller (Clojure team)17:10:06

1.9 beta 1 to us signals that the first part (deciding what features to include and provide) is over

Alex Miller (Clojure team)17:10:20

1.9 rc1 signals that we believe the major bugs have been fixed

Alex Miller (Clojure team)17:10:37

That said, I think the two approaches are to use clojure-future-spec with 1.8 or to separate your specs from your core so that you can build and deploy with 1.8 but test with 1.9 if you like


Understood. My point was more that clojure.spec is (almost) the only new thing in 1.9 so the risk of using the current alphas is actually very low, as far as existing 1.8 behavior is concerned.


I like the suggestion to have a 1.8-buildable system and an option to test against 1.9 with spec on top of that.


For us, we’ve used Clojure Alpha builds in production dating back to 1.3 Alpha 7 or 8 in 2011 and we’ve found it amazingly stable. We find the benefits of being able to leverage new features far outweighs the risks and I think we’ve only had to roll back one or maybe two prerelease builds in those five years.

Alex Miller (Clojure team)17:10:17

@seancorfield we’ve had several regressions related to the changes in destructuring and namespaced map syntax


Yup, and there are often small regressions or breaking changes in each release but those have either not affected us or been very minor impact issues.


I can certainly understand some companies being alpha-averse tho’. With some of the projects I maintain, I’ve encountered companies who won’t even consider an RC build. I find the most risk-averse companies tend to be the ones with the worst test coverage and therefore more likely to be unable to detect a regression in their own code… 😐


I think the Clojure/core team has done an incredible job of stability with Clojure releases over the years.


We always run our test suite against both our regular selected Clojure release and against Clojure master snapshots to catch any new breaking changes early.