On Thursday, June 16, 2016 at 6:11:19 PM UTC-5, Leif wrote:
>
> I’m having fun playing with clojure.spec, and I’ve written specs for most 
> fns in clojure.core
> and 1/3rd of the macros (WIP). Here they are in case you want to play 
> along:
>
> https://github.com/leifp/spec-play
>
> Bear in mind that official specs are forthcoming, I hear, and that my 
> specifications may be
> somewhat inaccurate. Some will also lock up your REPL if you turn on 
> instrumentation.
>
Seems like those specs should be vetted more then. :)
 

> Usual OSS warranty applies.
>
> Questions / comments / criticisms / witticisms / PRs welcome.
>
With the caveat that the Clojure team will be working on a different 
official set. I don't plan to look at this repo as it's not governed by the 
CA and not managed by the Clojure processes.
 

> Some questions / thoughts / points of discussion that arose while I worked 
> on this:
>
>    1. The any generator seems to only produce collections. That’s not 
>    quite as general as I
>    thought it would be. Does any test.check expert know if that’s 
>    expected, or am I using
>    the wrong generator?
>
> I observe the same thing, so I don't think you're doing anything wrong. 
gen/simple-type-printable probably gives you more of the things you expect, 
so maybe there is a reason to mix the two in our standard any generator. If 
you wanted to file a ticket for it, that would help me remember it.

>
>    1. Sometimes I wanted to count arbitrary, possibly infinite, 
>    collections, because return
>    values depended on the count. Does anyone have a safe way of doing 
>    this? I think
>    (count (take n coll)) might be safe, but other suggestions are welcome.
>
> I don't think there is a generally safe way to do this.

>
>    1. Philosophical question regarding already existing code: Do you 
>    think we should write
>    the spec that we *want* the fn to satisfy, or the one in the 
>    docstring, or the spec that it
>    *currently* satisfies?
>
> This will be a judgement call depending on the function. I believe there 
are probably many cases where people have incorrect expectations for the 
behavior of a function in core and undoubtedly we will find some that seem 
to be incorrect. I think as a general rule we will err on the side of 
"existing code that works should continue to work".

>
>    1. Fns with :inline metadata forms don’t get checked when they are 
>    instrumented. That
>    is because they are secretly macros at that point, but it’s something 
>    to be aware of.
>
> Yes, this is a known limitation of instrument and we don't currently have 
any plans to address it. 

>
>    1. Type checking vs. specification & their relationship
>       - The specs I wrote for higher-order fns are woefully imprecise, 
>       and I could not figure
>       out how to fix that. That may be due to me, but here are some 
>       thoughts: 
>       - Lots of specs depend on the fn arity and constraints between the 
>       specs of the args
>       and the return value. Then add in polymorphism. Sigh. I just wasn’t 
>       up to the task.
>       Type checking has some obvious advantages here, being designed for 
>       this case. 
>       - The friction here, I think, is that clojure.spec is 
>       understandably oriented around data.
>       Functions in clojure are technically data, but an opaque, 
>       uncommunicative form of
>       data. Me: “What’s your arity, fn?” Fn: *hostile silence* 
>       - In conclusion, what’s your take on the proper relationship 
>       between specification and
>       type checking?
>    
> I don't know that I have a blanket answer for this - in some cases fspec 
can be used for this, but it has limits. Again, I think this will be a 
judgement call between what we can and should express to be the right 
combination between useful, performant, and correct.

—Leif
> ​
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to [email protected]
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
[email protected]
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to