Looking to take a generated value and test it for just enough type information to generate a valid random function that transforms it in some way. Does something like this already exist in the wild?
> Can't say I understand the question to be honest... Do you have an example? -- @pavlos
Something like this (where gen and prop come from test.check), but with a lot more possible transformations, and ideally able to provide a meaningful selection of functions for any value generated by gen/any.
(def int-fns [inc
(partial * 3)
str])
(defn gen-transform [x]
(cond (int? x) (gen/one-of (map gen/return int-fns))
:else :not-implemented))
(gen/sample (gen-transform 2))
(defspec foo-equiv-to-bar
(prop/for-all [x gen/small-integer]
(gen/let [f (gen-transform x)]
(= (foo f x) (bar f x)))))This sounds like a solution to a problem. Do you have a goal or is the question philosophical in a sense? 🙂 (Both are fine but you might get better answers for a more specific problem) Perhaps you're trying to do a kind of coercion, in which case https://github.com/exoscale/coax might help
I am trying to test higher order functions, including such things as this functor law.
fmap (f . g) == fmap f . fmap gThis law says that for any function f and any function g, mapping f over the functor and g over the result is the same as mapping (comp f g) over the functor.
And I would like to generate a reasonable and varied set of functions to represent "any function" in testing that.
I see... That's an interesting puzzle 🙂
I don't think I can help, sorry... I can't imagine how you'd pick a compatible function on the fly based on randomly generated data without having a curated set of functions + metadata specs
If you have a set of functions and they are specced, you could use their input specs to generate the data after you've picked the function
But I suspect that won't cut it for you
Yeah, I think v1 would be a collection of curated functions mapped to acceptable input types, and randomly picking from matches, very similar to my example but lots more code. But Clojure and test.check definitely supports going a lot farther than that.
Reading through this additional context, it sounds like exactly the type of property that Typed Clojure could help verify; it has the ability to instrument codebases without requiring those codebases to depend on Typed Clojure. https://github.com/typedclojure/typedclojure/tree/main/example-projects/zero-deps
Interesting direction to go. 🤔
@pavlos has joined the channel