[clojure.spec] Best practices for programmatically generating specs?

[Aaron Brooks]

I've found in several projects that I want to have families of specs that have some shared structure but some differing structure.

Consider a case where I have some, possibly nested, structure which in some cases will have some type of  place-holder values which will later be replaced with actual values. I don't want a spec to have an 's/or at each position that could have a place-holder since I expect the structure to be populated with only place-holder values or only resolved values and want to exclude a mix.

Neither do I want to maintain two versions of the spec by hand. Some of the structure is complex and would be a pain to keep the two in sync.

This appears to leave two choices.

I'd like to describe the spec and then walk the spec, generating the other spec instance. Due to the macro-y nature of spec, I think this means eval which makes this not cljc/cljs friendly for self-hosted ClojureScript.

The alternative seems to be to build a set of macros that will generate both forms of the specs. This is awkward since it requires the full spec to be defined within the macro form and winds up being much more complex than a walk-and-transform of one spec into another.

What is the best practice for generating specs like this? Am I missing something?

I'm afraid the current macro-y, non-data-y implementation of clojure.spec.alpha really renders certain usage patterns (say specs that are derived from meta-specs) very awkward or inaccessible. I know spec needs to capture symbols and forms but wish that was a ease interface on top of a data oriented implementation that was first-class.

Let me know if I'm missing something in how I'm thinking about this or what my available options are.

Thanks!

-Aaron

[Alex Miller]

Another possible option is using spec specs (CLJ-2112) to unform from a spec data form to a spec (but that would still need to be evaluated) - still very much a wip.

However, we are working on a spec update that will target some of this, so stay tuned for that.

[Aaron Brooks]

An eval requirement will still be an impediment to me but it's good to hear that things are still being worked on. I'm happy to do any early testing of proposed approaches and give feedback.

Thanks for letting me know -- keep us posted!

-Aaron