On Wednesday, October 26, 2016 at 2:59:19 PM UTC-5, Yannick Scherer wrote: > > Sometimes, there are relationships between different parts of data that > need to be included in the spec. > This can surely be done using "s/and" >
s/and is precisely a way to add an additional constraint on an existing spec > and a predicate but this way we lose granularity when it comes to > the output of "s/explain" – we'll only ever see _that_ something is wrong > but never where exactly the > problem lies. > I don't think this is necessarily true - you lose granularity in the example you give because you use an opaque predicate. If the additional constraint is itself a structured spec, then you do not lose granularity. > Specifically, one might be able to generate the spec for one part of the > data from another. For example, > there could be a section of variable definitions, plus a different one > where those variables are used, and > the second part could benefit from a specification restricting the value > space for variable names. Which, > in turn could be generated from the first part. > Spec forms are data and can be conformed against s/form specs (not yet released) to produce more map-like data suitable for driving data generation if you like. So this is perfectly ok and something people are already doing in a bunch of different ways. > Alternatively, this could be expressed as a specialisation of an existing > spec, i.e. saying "The data conforms > to spec A and, additionally (!), every value within conforming to spec B > also conforms to a third one, C." > I think if you need to do this in some static way, you are better off writing the more precise spec (you can use both at different points in your process, and probably derive the specific parts partly from the generic in many cases). If you need to do it in a dynamic way, you should use your specs as data to generate dynamic specs. > (I also collected these thoughts in this Gist: > https://gist.github.com/xsc/bd4c498dc516435c71d01b4fdd224e85) > > Is this, at all, in line with the ideas behind spec? IMO, it could be a > powerful tool – my target use case being > semantic validation of an AST where the AST's structure conforms to a spec > bundled with the parser. > As I said, others are already doing this kind of thing with the tools already in spec. One example that comes to mind is dspec <https://github.com/lab-79/dspec> - which lets you generate Datomic schema and specs from an entity model. > > Cheers, > Yannick > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to [email protected] Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
