[m-dev.] for review: quickcheck user guide

[Mark Anthony BROWN]

Fergus Henderson writes:
> On 12-Feb-2001, Mark Anthony BROWN <dougl at cs.mu.OZ.AU> wrote:
> > Xiao Chun Simon MEI writes:
> > > +:- module use1.
> > > +
> > > +:- interface.
> > > +
> > > +:- use_module io.
> > > +
> > > +:- pred main(io__state, io__state).
> > > +:- mode main(di, uo) is det.
> > > +
> > > +%-------------------------------------------------------------------%
> > > +
> > > +:- implementation.
> > > +
> > > +:- import_module int, list.
> > > +:- import_module qcheck, testrev2.
> > > +
> > > +%-------------------------------------------------------------------%
> > > +
> > > +main -->
> > > +     	qcheck(qcheck__f(testing2), "testing2").
> > > +
> > > +%-------------------------------------------------------------------%
> > > +% 	Invariant test functions
> > > +%-------------------------------------------------------------------%
> > > +
> > > +:- func testing2(list(int), list(int)) = property.
> > > +testing2(Xs, Ys) = (Left `===` Right) :-
> > > +	testrev2((Xs ++ Ys), Left),
> > > +	testrev2(Ys, Part_a),
> > > +	testrev2(Xs, Part_b),
> > > +	Right = Part_a ++ Part_b.
> ...
> > > +An alternative to write use.m which does not evolving writing a separate 
> > > +invariant function, (use11.m):
> ...
> > > +:- module use11.
> > > +
> > > +:- interface.
> > > +
> > > +:- use_module io.
> > > +
> > > +:- pred main(io__state, io__state).
> > > +:- mode main(di, uo) is det.
> > > +
> > > +%--------------------------------------------------------------------------%
> > > +
> > > +:- implementation.
> > > +
> > > +:- import_module int, list.
> > > +:- import_module qcheck, testrev.
> > > +
> > > +%--------------------------------------------------------------------------%
> > > +
> > > +main -->
> > > +    qcheck(qcheck__f(func(Xs `with_type` list(int), Ys `with_type` list(int))
> > > +		     = testrev(Xs ++ Ys) `===` (testrev(Ys) ++ testrev(Xs))),
> > > +           "sample testing").
> > > +</pre></tr></table>
> > 
> > This is a fairly normal use of higher order code, and probably doesn't
> > need its own example.
> 
> I disagree here; I think it's worth showing the higher-order code as
> well, to encourage people to use a higher-order style when
> appropriate.  But the original code is probably easier to understand
> on a first reading, so IMHO both examples should stay.
> 

Fair enough.

> In fact there is one fairly subtle point about the higher-order example,
> namely the use of `with_type`.  The tutorial should explain why that
> is needed.
> 

>From reading it, it sounded to me as if the second example was introducing
some special syntax for use by qcheck tests.  This is a bit misleading,
since the syntax for higher order terms is, of course, more generally
usable.  So I think it would be best to write something like:

	An alternative to writing a separate invariant function is to
	use Mercury's syntax for higher order terms.  When doing this,
	the `with_type` operator can be useful to provide fixed types
	for the arguments of the invariant function.  For example:

etc.

Cheers,
Mark.

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------