[Haskell-cafe] Re: [Haskell-beginners] Just how unsafe is unsafe
Alberto G. Corona
agocorona at gmail.com
Fri Feb 6 16:17:56 EST 2009
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
2009/2/6 Roel van Dijk <vandijk.roel at gmail.com>
> On Fri, Feb 6, 2009 at 5:22 PM, Alberto G. Corona <agocorona at gmail.com>
> > 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
> > 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
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe