(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

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

Reply via email to