Fork me on GitHub
#clojure-spec
<
2017-03-08
>
nwjsmith18:03:58

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

nwjsmith18:03:45

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

nwjsmith18:03:22

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

nwjsmith18:03:03

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.

tbaldridge18:03:51

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.

ghadi19:03:14

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

alexmiller19:03:14

why do you care?

alexmiller19:03:12

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

alexmiller19:03:29

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

alexmiller19:03:36

or memoize s/valid?

alexmiller19: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?

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

alexmiller19:03:00

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

nwjsmith19:03:26

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

nwjsmith19:03:27

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

nwjsmith19:03:28

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

ghadi19:03:07

@alexmiller that makes sense, thx

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

alexmiller20:03:58

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

nwjsmith20:03:54

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.

wei21:03:40

does anyone use arohner/spectrum and recommend it?

alexmiller21:03:25

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

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

arohner22:03:40

It is being developed, but I’m very busy

arohner22:03:10

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

arohner22:03:28

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

wei22:03:22

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

wei22:03:29

if it works, it would be amazing!