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 <vandijk.roel@gmail.com>
On Fri, Feb 6, 2009 at 5:22 PM, Alberto G. Corona <agocorona@gmail.com> wrote:
> then Data.List.head   Data.Maybe.fromMaybe etc are also unsafe?.
Yes, I consider them unsafe. Whenever I see those functions I know
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.