Then you are talking about something very different from the subject that Andrew started.. He clearly ask about "unsafeXXX understood as impurity "which defiles our ability to reason logically about haskell programs like we would like to". I also want to discuss here that any signature of type IO a -> a defies also the ability to reason of the compiler evaluation algoritm. For example i sometimes find strange differences between using and not using unsafePerformIO. It seems that, when the result of a IO action is converted in pure, if the variable becomes out of scope, the garbage collection can drop some data that is needed for the next call to the IO function to work properly. this does not happens if the calls are executed inside the IO monad. Alternatively, it could be that the some necessary state is lost. This happens for example with the System.Mem.StableName.makeStableName method and some others that I do not remember now. I would like to know if this is due to some general cause or if it is library specific. 2009/2/6 Roel van Dijk

...

then Data.List.head Data.Maybe.fromMaybe etc are also unsafe?. Yes, I consider them unsafe. Whenever I see those functions I know

On Fri, Feb 6, 2009 at 5:22 PM, Alberto G. Corona wrote: that I have to look elsewhere to see if their preconditions hold. I would have preferred that listToMaybe was called head and the existing head called unsafeHead, partialHead or something else of that nature.

...

unsafe does not mean "with possible errors". unsafeXXX convert something in the IO monad into something that is not. So it can potentially contaminate your pure code. But Data.List.head applied to a empty list will interrupt the computation abruptly, so your code using head will either run side effect free or not run at all. I guess what unsafe should mean is a matter of taste. Personally I find correctness more important that pureness. An unsafe function will crash your program if evaluated when its preconditions do not hold. Whether that is because of impurity (segmentation fault?), a partial pattern match or a direct error "bla" is not that important. It might be important when determining why your program crashed, but the result is still the same.

The ByteString library has a module called Data.ByteString.Unsafe with plenty of unsafeXXX functions. The comment for unsafeHead for example states: "A variety of head for non-empty ByteStrings. unsafeHead omits the check for the empty case, so there is an obligation on the programmer to provide a proof that the ByteString is non-empty." That perfectly reflects my own philosophy on this issue.