On Sunday, November 6, 2016 at 5:01:23 AM UTC-6, Jim foo.bar wrote: > > Hi all, > > Without having looked at the test.check internals, I'm trying to figure > out roughly what kind of generator function, the following spec will give: > > (s/def ::predicate (s/fspec :args (s/cat :x any?) > :ret boolean?)) > > fdef or fspec will generate a function that checks that assert the incoming args match the :args spec and then return a value generated by the :ret spec.
> So, I'm trying to sort of reverse engineer it on the repl: > > (def p (second (first (s/exercise ::predicate 1)))) > => #'specs.encore/p > p > => > #object[clojure.spec$fspec_impl$reify__14282$fn__14285 > 0x5cb07a8d > "clojure.spec$fspec_impl$reify__14282$fn__14285@5cb07a8d"] > (p 1) > => false > (p []) > => false > *(p :a)* > *=> true * > (p :b) > => false > *(p :a)* > *=> true* > *(p :a)* > *=> false* > > Ok, so the predicate returned does not always return the same boolean > value (so not constructed via `constantly`). But it also returns a > different boolean, given the same argument (so not a real predicate in the > sense that it looks at the argument and then decides)! Only one option > remains, as far as I can see...`p` seems to return true or false randomly. > Can anyone confirm this? > This is consistent with my description above. > If my understanding is correct, how would one write the :fn spec of a > function like `clojure.core/remove`? Wouldn't it make sense to try to > verify that the :ret collection does NOT contain any elements satisfying > the predicate used? Similarly for `clojure.core/filter`. A reasonable :fn > spec for it should try to confirm that ALL elements in :ret satisfy that > predicate used, right? But if the predicate generated returns true/false > randomly, one cannot reliably use it under the :fn spec. Unless, I'm > missing something of course...Thanks in advance :) > You can write a :fn spec that does all of those things, however the generated function spec will not verify those. It would maybe be a reasonable enhancement to verify that the :fn spec is satisfied wrt the passed args and the generated :ret value (by adding a such-that generator based that enhances the ret generator. This is likely to make function generators work harder / fail more easily, but you would have greater guarantees when it did pass. Seems worthy of an enhancement ticket. You can use stest/instrument to supply alternative specs and/or generator overrides for a function and that would be my recommended strategy right now. > Kind regards, > > Dimitris > > > > > > -- 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.
