Improvements to the code

[c-cube]

I've started refactoring the code, eliminating warnings, getting closer to -safe-string compatibility, and started adding doc (I missed (*$inject and discovered it by reading the lexer...). Could the doc, maybe, be written in something like markdown or asciidoc rather than LaTeX?

I'm planning to change the API of the quickcheck library to make it more powerful and closer to the original QuickCheck (shrinking, etc.). I read that a qtest 3 was not impossible in principle, so I want to change 'a gen_print into an object with a generator and several optional methods for printing, shrinking, etc.

Do those more ambitious changes have a change to be merged?

[vincent-hugot]

Hello,

Thanks for the quick fixes.

Yes, more ambitious changes have a good chance to be merged; but anything that breaks compatibility for users of the current version would have to go in a new qtest3 folder as a new, separate, full-fledged version.

Could the doc, maybe, be written in something like markdown or asciidoc rather than LaTeX?

I'm not volunteering for the transition of the existing doc; and don't see what would be gained by that.

[c-cube]

About the doc, well, writing LaTeX only to compile it to html seems overly complicated to me. I do think markdown is simpler. Anyway, the first thing to do on documentation is filling the blanks, I discovered (*$inject by chance!

The "ambitious changes" I'm talking about would be:

• allow for sized generators (keep regular generators as a special case, of course, so compatibility ✔)
• redefine ==> to work on properties, not mere booleans (in a ==> b, if a is false, then count it as a trivial case and try and generate more tests. For 100 tests we can generate as many as 1000 pairs a ==> b if necessary, as in the QuickCheck paper).
• put small into the generator itself (makes sense for already defined generators, such as list)
• propose shrink: 'a -> 'a list as an alternative to small, so as to try to shrink counter-examples by removing elements one by one
• improve the set of combinators (exposing, for instance, oneofl or frequency).

I don't think any of those changes is deeply breaking: a simple use of (*$Q will use the same combinators. However, if people defined their own combinators some corner cases would probably change. Anyway, the current branch already contains the slightly-breaking "replace Random with Random.State".

What do you think?

edit: cf #19