Fork me on GitHub

I’ve really enjoyed working with spec the past few months, but there is a problem that’s crept up again and again: specs are objects, and can only be manipulated w/ the closed set of operations provided by the clojure.spec ns


Time and time again, I’ve found myself wanting to manipulate the structure of a spec.


But the only way to do that is to parse the spec’s form.


If specs were represented as data structures rather than as opaque objects, I think it would open up a lot of possibilities. I’m sure there are reasons (performance and the alpha API status) that make it more desirable to have specs represented as they currently are. Hopefully somewhere down the line this kind of thing will be made, ahem, easier.


I agree, metaprogramming of specs is something I'd like to see explored. Pretty much the only missing part IMO, is the specs-for-specs thing you linked above.


Unrelatedly, one thing that has been mentioned before was this scenario: You have a bunch of functions that are processing some map input. If you knew at the outset the specs of all the function, you'd be able to check everything before processing, Will this not repeatedly check specs for all qualified keys in the input map? Or is there some way to avoid that

Alex Miller (Clojure team)19:03:12

if you’re doing this at dev or test time, then maybe don’t worry about it.

Alex Miller (Clojure team)19:03:29

if you’re validating in production, then validate once at the entry point, and don’t validate in each step

Alex Miller (Clojure team)19:03:31

@nwjsmith specs (as macros) capture their form for error reporting. if you are somehow manipulating the spec, the form is not going to track those changes. this seems bad?

Alex Miller (Clojure team)19:03:39

is the stuff in CLJ-2112 (as a Rush fan, I can’t really say how happy I am this happened to be ticket 2112, plus it is trivial for me to remember it) sufficient? If not, what’s missing? Note that you can start with a spec form, conform it to data, modify the data, then unform it back to a spec form

Alex Miller (Clojure team)19:03:00

for that matter, you don’t even need the initial form - just build the conformed data, then unform


Yes, that would be sufficient. I hadn’t thought about the form capturing, which would make manipulating specs-as-data ridiculous.


What if there was no form capturing though? And spec just provided terrible error messages?


I suppose I'll sit here waiting for CLJ-2112 to drop, soothed by the sounds of Geddy Lee and Neil Peart.


@alexmiller that makes sense, thx

Alex Miller (Clojure team)20:03:26

@nwjsmith well a still possible option is to provide function-level entry points for specs that did not have the ability to use forms in explain (or rather you’d have to supply those if you wanted them)

Alex Miller (Clojure team)20:03:58

I guess in some ways the functions under the existing macros are that, although they are not designed to be public


I think being able to conform, manipulate, and unform the spec forms should be enough. It would be nice to maintain the behaviour of explain through such a manipulation.


does anyone use arohner/spectrum and recommend it?

Alex Miller (Clojure team)21:03:25

@nwjsmith I think you would retain that as you’re going back through to the form

Alex Miller (Clojure team)21:03:13

@wei I saw his talk at the conj on it and was pretty impressed. it was unclear whether development on it was going to actively continue though


It is being developed, but I’m very busy


I’m working through filter, and I have a few hundred lines that haven’t been pushed yet


but yeah, it’s not ready for real use yet


@arohner thanks for working on it, seems like a lot of people are excited about the prospect of static analysis at compile time


if it works, it would be amazing!