Re: instrumenting clojure.core

Thanks Alex, I was experimenting along similar lines. It might work since the lazy seq is not realized at this point and :f might not have been called. Otherwise the last clause would always hold true or never be called (due to earlier ArityException). It covers more of a test for map itself (h

Re: instrumenting clojure.core

I think map is a good example where the different arities have very different semantics, and maybe it would be practical to specify a separate spec for each arity. In the unified spec, both :args and :ret have to resort to (more or less explicit) unions in order to express the sum of the separa

Re: instrumenting clojure.core

I was suggesting that you could do something like this (although I'm pretty sure this doesn't work right now): (s/fdef map :args (s/cat :f (s/fspec :args (s/+ ::s/any)) :colls (s/* seqable?)) :ret (s/or :seq seqable? :transducer ifn?) :fn #(if (zero? (count (-> % :args :colls

Re: instrumenting clojure.core

Oh, I see what you mean now, Leon. Apologies for not reading more closely! Yours is a much more interesting puzzle. Here's an attempt I made , groping towards it using reflection, but I couldn't even get that to work. Would be curio

Re: instrumenting clojure.core

Thank Alistair, but that does not really address my question. Alex suggested using :fn of fspec to check arity of a higher-order argument. But I could not find a tool to check function arity. Also I doubt :fn is going to work since I'd expect it to be invoked /after/ the call - i. e. the call w

Re: instrumenting clojure.core

> On Jun 12, 2016, at 10:45 AM, Alex Miller wrote: > > Still much to be determined about this but I expect that specs for core will > be provided and maintained by us, because while there are a lot of obvious > specs in core, there are also a lot of far more subtle ones. I think this is the ri

Re: instrumenting clojure.core

Hi Leon, I think you're looking for fspec , unless I'm misunderstanding something. I wrote up an example that might be helpful. @Ryan t

Re: instrumenting clojure.core

Alex, thank you for the long and detailed response. The direct linking issue and Ryans last example make me wonder whether the hard rule "If A and B are both instrumented and if A ever calls B violating B's spec, A's spec is broken" holds? If so the direct-linking issue would probably be a n

Re: instrumenting clojure.core

On Sunday, June 12, 2016 at 9:22:24 AM UTC-5, Leon Grapenthin wrote: > > That looks great already. I'm also interested in what the official > workflow for adding specs to core is going to be and whether contributions > are desired. > Still much to be determined about this but I expect that spec

Re: instrumenting clojure.core

That looks great already. I'm also interested in what the official workflow for adding specs to core is going to be and whether contributions are desired. The last example seems like it could be better because the user has to infer how identity was called within map. So what we'd want is a cod