(Reviving an old message here. You can see the original message at http://www.stud.tu-ilmenau.de/~robertw/haskell/doc/contract_notations.lhs ) On Tue, Feb 17, 2004 at 10:50:30AM +0100, Robert Will wrote:
4. A notation for preconditions. ... Presently I use the following coding style:
take n xs | not (n >= 9) = error "take.Precondition"
The precondition can simply be extracted as <<the bracketed expression behind @not@ in a line containing the words @error@ and "Precondition">>.
However it has the disadvantage that I can't simply disable run-time checking of the Precondition (as I could when using @assert@). Furthermore it is also rather ugly. Does anyone have a better idea?
This doesn't help with ugliness, but you could define an auxiliary function:
take n xs | check (n >= 9) = error "take.Precondition"
check :: Bool -> Bool check = not
or, for testing,
check = const True
5. Default implementations of type class members are often a special case of specification functions: the overwriting provides the same semantics, more efficiently. (Occurs often in Abstract Data Structures, see [2].)
A typical example is:
is_empty coll = size coll == 0 -- ||
We can use the double bar (or whatever we decide to standardise), to mark the function definition for export to the documentation. However, it is more difficult to create test properties which compare the two implementations of a function, since the default implementation is no more accessible after having been overwritten. The property generator will have to copy the default definition to a definition with name @is_empty_spec@ (for example) and can then generate the usual @prop_is_empty_spec@ (as in point 2). The copying of the function definition happens only for testing and is not seen in normal code or documentation.
I'm not sure how relevant it is, but one thing I found when working on revising the numeric hierarchy in the Standard Prelude was that I often wanted a default implementation that I had "standard" default definitions that I couldn't actually make a default class instance, because of the way the hierarchy was built up. For instace, with exponentiation, there are two default definitions, one that works with positive powers and one that works with positive and negative powers, but only in the subclass with division. The current standard has, in a fairly ugly way, two different operators for these two functions; I preferred to combine the two by making the operation a class member. I hope your standard would provide an obvious way to name such default definitions which work only in a subclass. Peace, Dylan