Then you are talking about something very different from the subject that Andrew started.. He clearly ask about &nbsp;&quot;<span class="Apple-style-span" style="border-collapse: collapse; ">unsafeXXX understood as &nbsp;impurity &quot;which defiles our ability to reason logically about haskell programs like we would like to</span>&quot;.<div>
<div><br></div><div>I also want to discuss here that any signature of type IO a -&gt; 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, &nbsp;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 &nbsp;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 &nbsp;System.Mem.StableName.makeStableName method and some others that I do not remember now.&nbsp;</div>
<div><br></div><div>I would like to know if this is due to some general cause or if it is library specific.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br><br></div><div><br><div class="gmail_quote">
2009/2/6 Roel van Dijk <span dir="ltr">&lt;<a href="mailto:vandijk.roel@gmail.com">vandijk.roel@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="Ih2E3d">On Fri, Feb 6, 2009 at 5:22 PM, Alberto G. Corona &lt;<a href="mailto:agocorona@gmail.com">agocorona@gmail.com</a>&gt; wrote:<br>
&gt; then Data.List.head &nbsp; Data.Maybe.fromMaybe etc are also unsafe?.<br>
</div>Yes, I consider them unsafe. Whenever I see those functions I know<br>
that I have to look elsewhere to see if their preconditions hold. I<br>
would have preferred that listToMaybe was called head and the existing<br>
head called unsafeHead, partialHead or something else of that nature.<br>
<div class="Ih2E3d"><br>
&gt; unsafe does<br>
&gt; not mean &quot;with possible errors&quot;. unsafeXXX convert something in the IO monad<br>
&gt; into something that is not. So it can potentially contaminate your pure<br>
&gt; code.<br>
&gt; But Data.List.head applied to a empty list &nbsp;will interrupt the computation<br>
&gt; abruptly, so your code using head will either run side effect free or not<br>
&gt; run at all.<br>
</div>I guess what unsafe should mean is a matter of taste. Personally I<br>
find correctness more important that pureness. An unsafe function will<br>
crash your program if evaluated when its preconditions do not hold.<br>
Whether that is because of impurity (segmentation fault?), a partial<br>
pattern match or a direct error &quot;bla&quot; is not that important. It might<br>
be important when determining why your program crashed, but the result<br>
is still the same.<br>
<br>
The ByteString library has a module called Data.ByteString.Unsafe with<br>
plenty of unsafeXXX functions. The comment for unsafeHead for example<br>
states: &quot;A variety of head for non-empty ByteStrings. unsafeHead omits<br>
the check for the empty case, so there is an obligation on the<br>
programmer to provide a proof that the ByteString is non-empty.&quot; That<br>
perfectly reflects my own philosophy on this issue.<br>
</blockquote></div><br></div></div>