[Haskell-cafe] Use unsafePerformIO to catch Exception?

Alexander Dunlap alexander.dunlap at gmail.com
Thu Mar 26 20:42:40 EDT 2009


On Thu, Mar 26, 2009 at 5:23 PM, wren ng thornton <wren at freegeek.org> 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


More information about the Haskell-Cafe mailing list