>>>>> "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
