I'd like to ship a library without requiring test.check, and have the generators dynamically loaded as they are with clojure.spec, but I can't figure out how to do that. Do I wrap all calls to clojure.spec.gen functions in clojure.spec.gen/delay?

(the library is essentially a bunch of specs, some of which require custom generators)

that is kind of interesting to think about, if you are defining custom specs with generators in your source, then test.check needs to be a regular dependency not a test scoped dependency

a delay delays runtime code from running, not compile time stuff

like var resolution

you likely need some combination of something like dynaload from clojure.spec.gen and the delay there and maybe clojure.core/delay

or just put your generators in another namespace?

that would still have issues with any kind of tooling that loads all namespaces (in the absence of test.check)

what kind of tooling does that? seems kinda like a bad idea 😛

I was thinking of stuff like lein check, but that only loads stuff from the current project

on another track…. 1st order predicate expressions and regular languages are closed under intersection — would be cool if somebody wrote an ‘intersect’ function for spec, could be useful for static analysis

@bbloom: elaborate?

@arohner: well you could just write an abstract interpreter that walks the clojure AST and instead of an environment of symbols -> values, have an environment of symbols -> specs

oh, yeah

each time you use something, you call intersect on it

if the result is void, you have a "type error"

yeah, just wasn’t sure what you meant by intersect

I have about half of that written

currently reimplementing the regex part of spec to handle it

if each spec defines a set, intersect = set intersection

intersecting two predicates is just and-ing them, but you could do better for some predciates, cat, repeat, alt, etc

yeah, it’s a lot more work than that 🙂

certainly not trivial, but should be at least straightforward, no?

yeah

parsing specs and the regex stuff is straightforward, but a ton of code

same w/ flowing predicates through a fn body

yeah, i have a clojure interpreter that i’ve copy/pasted and modified 4 or 5 times for code walking purposes - someday i’ll make it a library

in the mean time: https://github.com/brandonbloom/metaclj/tree/master/src/metaclj/impl

the transform namespace is an example of a code walk on that ast & you could replace that with a type check walk

here’s an interpreter: https://github.com/brandonbloom/eclj/blob/master/src/eclj/interpret/meta.eclj

I’m already walking the tools.analyzer output, so it’d be a good amount of work to swap

not suggesting that you switch to my thing 😛 just showing that it can be much less code than tools analyzer, which does all the analysis all at once

anyway @arohner: excited to see what you come up with 🙂

yeah, me too. Just need to finish the regex matching crap

the first big question about clojure.spec that I'm going to try to dive into is how I can get functionality similar to https://github.com/gfredericks/schema-bijections

so I suspect (ha!) I'll be reading a bunch of the clojure.spec source soon

is it weird that s/tuple takes preds instead of specs?

I thought preds were specs

I have a tuple '(s/def ::color (s/tuple ::byterange ::byterange ::byterange ::byterange))' that seems to work @gfredericks

as of now, I have successfully converted my project from plumatic.schema to cljs.spec!

still have a lot to learn about it, but it sure is nice

benzap: yeah it does seem to work, but that means the docs are misleading I think: preds are specs but specs aren't preds