What I do like about this so-called "negative" approach is that it represents a part of a program's documentation that is usually omitted. You can look at the code and see exactly how and (to a certain extent) why the program does what it does, but what you can't see is all the things it doesn't do, and the reasons it doesn't do them. This can be extremely important to know when you are thinking about modifying a program. The change you are considering may have already been tried and rejected, but unless these sorts of negative decisions are documented in the software you may end up spinning your wheels.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
