On Thu, Mar 26, 2009 at 5:23 PM, wren ng thornton <[email protected]> wrote: > Jules Bean wrote: >> >> wren ng thornton wrote: >> > I have long been disappointed by a number of `error`s which shouldn't > >> > be. For example, the fact that `head` and `div` are not total strikes > me >> > as a (solvable) weakness of type checking, rather than things that > should >> > occur as programmer errors/exceptions at runtime. The use of > `error` in >> > these cases muddies the waters and leads to a laissez-faire > attitude >> > about >> > when it's acceptable to throw one's hands up in despair > and use `error` >> > rather than writing a better function. >> >> head uses "error" in precisely the correct, intended fashion. >> >> head has a precondition (only call on non-empty lists) > > And that is *exactly* my complaint: the precondition is not verified by the > compiler. Therefore it does not exist in the semantic system, which is why > the error screws up semantic analysis. > > The type of head should not be [a] -> a + Error, it should be (a:[a]) -> a. > With the latter type the compiler can ensure the precondition will be proved > before calling head, thus eliminating erroneous calls. > > It's a static error, detectable statically, and yet it's deferred to the > runtime. I'd much rather the compiler catch my errors than needing to create > an extensive debugging suite and running it after compilation. Is this not > the promise of purity?
Ultimately, it's not detectable statically, is it? Consider import Control.Applicative main = do f <- lines <$> readFile "foobar" print (head (head f)) You can't know whether or not head will crash until runtime. Alex _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
