>>>>> "Hamilton" == Hamilton Richards <[EMAIL PROTECTED]> writes:

    Hamilton> How about these definitions? They're like the Haskell98
    Hamilton> prelude definitions except that n<0 is always an error,
    Hamilton> even if the list is [].

the problem with an unnecessary restriction is that it complicates
reasoning about the program. 
Instead of

   xs
 = { take/drop-law }
   take (n-m) xs ++ drop (n-m) xs

you have to write, e.g.:

   xs
 = { restricted take/drop-law }
   if n<m then undefined else take (n-m) xs ++ drop (n-m) xs
 
The problem is that the "-" operator naturally can appear
if you perform cut and paste operations on lists, but
the natural numbers are not closed under negation.

If using a natural type, people will insist on having a partial
minus operation. How should the compiler check that this operation
is well-defined? If the compiler can't, why have this type at all
if the integers are available?

The advantage of solution (A) is that it makes a single principle
exception for values out of range: an unnatural definition,
but solution (B) makes two: undefinedness for negative values and 
an unnatural definition for values that exceed the size of the list,
i.e., (B) puts more work on the programmer.

In general, the larger a domain of an operation is, the simpler
is the handling. If, i.e., a division by zero produces a value
"div by zero" instead of an error message, 
subsequent operations may deal with it and the entire computation can succeed.

-- 
 Christoph Herrmann
 E-mail:  [EMAIL PROTECTED]
 WWW:     http://brahms.fmi.uni-passau.de/cl/staff/herrmann.html




Reply via email to