Fork me on GitHub
#clojure-spec
<
2016-10-26
>
gfredericks00:10:37

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

gfredericks00:10:50

I don't have any explicit keys

alexmiller00:10:12

Well then sounds good

alexmiller00:10:53

Any registered keys will get checked

gfredericks01:10:39

that would be bad actually

gfredericks01:10:01

I'm trying to spec gen/hash-map

gfredericks01:10:32

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

gfredericks01:10:50

and that's perfect

gfredericks13:10:13

So I'm specing some macros

gfredericks13:10:11

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

gfredericks13:10:51

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

gfredericks13:10:16

But anything fancier would be somewhat complex

gfredericks13:10:26

So I'm wondering if it's worth it

gfredericks13:10:47

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

moxaj13:10:10

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

alexmiller13: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

alexmiller13:10:57

and in that you should just omit it

alexmiller13: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

alexmiller13: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)

alexmiller13: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)

gfredericks14:10:52

That makes sense; thanks

quoll15:10:35

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.

trptcolin15:10:34

i haven't used it, but https://github.com/tonsky/clojure-future-spec is the effort i've heard about

seancorfield16:10:03

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

alexmiller16:10:09

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

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

alexmiller16: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

alexmiller17: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

alexmiller17:10:45

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

alexmiller17: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 :)

alexmiller17:10:06

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

alexmiller17:10:20

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

alexmiller17: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

seancorfield17:10:10

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.

seancorfield17:10:34

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.

seancorfield17:10:07

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.

alexmiller17:10:17

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

seancorfield17:10:01

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.

seancorfield17:10:35

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… 😐

seancorfield17:10:56

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

seancorfield17:10:49

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.