Algebra of compatibility in test.check

[Ghadi Shayban]

test.check's gen/pos-int currently returns 0.
Users of clojure.spec grabbing the generator for predicate c.c/pos-int? do not receive the 0 because spec filters generated values by the predicate:

user> (clojure.spec.gen.alpha/sample (clojure.spec.alpha/gen pos-int?))
(1 1 1 4 2 4 31 1 8 4)

user> (clojure.test.check.generators/sample clojure.test.check.generators/pos-int)
(0 0 1 1 0 5 1 2 1 4)

This seems like a bug in the underlying generator. Receiving 0 (probably) surprises users, but it's been like this forever.

There are at least these two options:
- Make a new corrected generator with a new name
- Correct the generator returned by gen/pos-int to never return 0, giving less cases to its users (spec users remain unaffected)

Does Rich's algebra of compatibility, namely functions providing less => breakage -- does that apply here? Changing the function returns a generator of random values - but one value would be missing.
(there's an old adage I'm butchering: eventually users rely on all program behaviors whether correct or not.)

[Alex Miller]

If it's broken, then that is independent of the contract and it should be fixed.

In Spec-ulation, Rich said: "And the other is fixation. And this is another cool thing. I looked up "fixation", and it actually means to fix things. It does not mean to be paranoid. So then the final thing is just fixing stuff, which does not impact what you provide or require. It just means you are now doing it correctly, or maybe faster, or maybe with fewer requirements. You know, fewer dependencies, or something else. But whatever. It does not impact what you provide or require."

[Gary Fredericks]

"broken" is a bit ambiguous here. The docstring does say "positive", but then there's another generator called s-pos-int whose docstring says "strictly positive" (and which excludes 0), which suggests that the word "positive" isn't being used the way I've normally seen it used.

I've always considered these generators to do what they're intended to do but to have confusing names based on some strange alternate meaning of "positive" and "negative". If that's what other users also concluded, then their use of pos-int might assume that zero will be generated, and therefore by "fixing" the generator we'd be reducing test coverage, at exactly one of the most important edge cases to check.

Gary Fredericks
(803)-295-0195
frederi...@gmail.com
gfredericks.com

--
You received this message because you are subscribed to the Google Groups "Clojure Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure-dev+unsubscribe@googlegroups.com.
To post to this group, send email to cloju...@googlegroups.com.
Visit this group at https://groups.google.com/group/clojure-dev.
For more options, visit https://groups.google.com/d/optout.

[Gary Fredericks]

What I'm arguing for is that a cleaner solution would involve some form of deprecation; I'm not sure what precedent there is in contrib libraries for how to do deprecation. I think java.jdbc has had deprecated functions, at least.

Gary Fredericks
(803)-295-0195
frederi...@gmail.com
gfredericks.com

[Alex Miller]

Mark pos-int as deprecated and point to a new generator function with a better name, like nat-int?

We mark stuff as deprecated in core with a :deprecated meta tag with a value that is a string containing the version when it was deprecated.

On Mon, Mar 5, 2018 at 8:07 PM, Gary Fredericks <frederi...@gmail.com> wrote:

[Gary Fredericks]

Okay I will head in that direction. Thanks!

Gary Fredericks
(803)-295-0195
frederi...@gmail.com
gfredericks.com