I’d advise everyone concerned/confused about the relationship between spec and
data representations to please spend some more time trying to understand spec
and, especially, dial back the rhetoric. I know what the Clojure philosophy is,
and it’s not some triviality.
specs are fundamentally code (predicates and logic)
Clojure code is a great data format for code, designed to be written and read
by humans. There is a reason we don’t write code in AST maps:
(if x y z)
vs
{:tag :if-expr :test x :then y :else z}
The ‘form’ function will return the spec as sexpr data. This is currently
missing gens but that will come (if gens don’t end up somewhere else entirely).
You can eval this data and get a running spec. Or not. If you don’t want to,
that doesn’t make the fact that you can bad. Data doesn’t run, so any
data-driven ‘language’ is going to need an interpreter/compiler.
Claiming sexprs aren't ‘data’ suitable for programmatic manipulation denies a
50+ year Lisp history.
Expecting runtime specs to ‘be’ data is no more desirable than leaving code as
data at runtime - it would always need interpretation. Runtime specs are (sets
of) functions, and are as binary as functions. What matters is that they are
available as data, which they are.
If you prefer an AST-like thing you are only a spec and conform call away from
it. This is the key point people are missing who haven’t used spec enough. If
you have an sexpr or other data-format syntax you don’t need to write a parser,
you need to write a spec. conform will destructure for you.
We intend to provide specs for spec which can be used for these and other
purposes.
Rich
> On May 25, 2016, at 7:11 PM, Leif <leif.poor...@gmail.com> wrote:
>
> I guess I'm confused why the Clojure philosophy of "data > fns > macros" is
> being ignored in this particular case, when the other schema libraries show
> that there is an army of end-users that want to do unexpected things with
> specifications, and to do that, it would be easiest if they had data IRs,
> c.f. the Schema model:
>
> macros to look nice ->
> data repr ->
> -compile to-> validator or
> -translate to-> data repr with subgenerators attached ->
> -compile to-> generator or
> -compile to-> ??? something a clever tester dreamed up ??? or
> -compile to-> fn returning nice error message or
> -compile to-> ??? something a clever user dreamed up ???
>
> I'll leave it at that, I've put my 6 cents in.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> 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 clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
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 clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
