Clojurians Log v2

@gfredericks what's going on with https://dev.clojure.org/jira/browse/TCHECK-2 ? we just got bit by that

what's a good solution w.r.t. not breaking things? deprecate the old poorly named things and make new things with good names?

i guess i'm confused on how it's poorly named vs broken

(pos-int? 0) => false

IIRC it just so happens that spec filters out by doing (such-that pos-int? gen/pos-int) -- but if you use test.check directly you'll see 0

yeah:

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)

I think it was always a case of a bad name; I have no idea where those names came from, but I think the docstrings have reflected the actual behavior

so changing the behavior & docstrings to match the names would potentially break anybody using them

ugh

what does the s in s-pos-int mean?

"strictly" -- which points even more strongly to the bad names theory

lmao

there's a relevant section on integer generators here: https://dev.clojure.org/display/design/Generators+Reboot

i see

in rich's compatibility algebra of provides and requires -- is not returning 0 a breaking change? Is it possible that certain random seeds never see 0?

I've wondered about how the compatibility algebra applies to generators and distributions 😄

I do think reducing the distribution is a breaking thing

you're silently causing users' generators to test less than they used to

my 2c: this generator is busted and it's not that big of a deal to remove 0. (There is an argument around people relying on behavior whether correct or not)

i can be persuaded either way -- but not for a crappy name like s-pos-int

no I don't think "leave everything as-is" is a good solution

given zero is such an important edge case a lot of the time, silently making people's tests less effective is also a bad idea I think

I think the bigger question that needs deciding is the one from the link above -- whether to start a new namespace or improve things by deprecating individual generators

I feel like rich's paradigm could use some good deprecation tooling

woah the spec alias of the exact same name has different behavior?

gee willickers

yup

maybe we should ask Rich on the mailing list

about deprecation or about generator aliasing?

The former

like whether deprecation is a good idea at all, or the specific question of how we should do it exactly?

what to do specifically

need a third set of eyes