IMHO  (and only IMHO)<div><br></div><div> In a pure context, a copy operation does not make any sense. Why duplicate a chunck of memory whose content is inmutable?. Just create another pointer to it !.<div><br></div><div>If you need to simulate the mutation of a variable in a imperative context, create a new closure and define a new variable with the same name. That is what monads do.<br>
<div><br></div><div> In a impure context, use IORefs.<br><br><div class="gmail_quote">2009/8/12 John Lato <span dir="ltr">&lt;<a href="mailto:jwlato@gmail.com">jwlato@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Job,<br>
<br>
I don&#39;t think this hypothetical function could exist; you may as well<br>
call it  &quot;notEverSafeOhTheHumanity&quot; and be done with it.<br>
<br>
Since Haskell provides no guarantees about when (if ever) any given<br>
function/data will be evaluated, you would need some mechanism to tell<br>
the compiler that a data chunk has a certain value at one time and a<br>
different value at another.  The language provides this in the IO (and<br>
ST) monads.  So the function would need to live within IO, and you<br>
don&#39;t gain anything.  If you try to take it outside of IO, with e.g.<br>
unsafePerformIO, then the compiler will no longer treat it like IO and<br>
the result is free to be evaluated whenever, so you&#39;re back where you<br>
started.<br>
<br>
Also, keep in mind that purity is a language requirement in Haskell<br>
and such a function really would &quot;break everything&quot;.  Specifically,<br>
you would get differing output depending on the exact transformations<br>
performed by the compiler, which in general would be difficult to<br>
predict in advance, probably not the same between different compiler<br>
versions, changed by compiler flags and phases of the moon, etc.  I<br>
have an example in a darcs repo somewhere...<br>
<br>
Cheers,<br>
John<br>
<br>
&gt; From: Job Vranish &lt;<a href="mailto:jvranish@gmail.com">jvranish@gmail.com</a>&gt;<br>
&gt; Subject: Re: [Haskell-cafe] unsafeDestructiveAssign?<br>
&gt;<br>
&gt; Ga! Before to many people start flooding me responses of &quot;This is really<br>
&gt; dumb idea don&#39;t do it!&quot; I would like to clarify that for the most part<br>
&gt; IKnowWhatI&#39;mDoing(TM)<br>
&gt;<br>
&gt; I am well aware of the usual ST/IORefs as the usual solutions to data<br>
&gt; mutability in haskell.<br>
&gt; I very very much understand purity, and why it is a good thing, and why we<br>
&gt; should try to stay away from IO and ST as much as possible.<br>
&gt; I am very much away that even if I had such a function that it will probably<br>
&gt; break everything.<br>
&gt; I am not just trying to make things run faster.<br>
&gt;<br>
&gt; What I am trying to do is hyper unusual and I really do need an<br>
&gt; unsafeHorribleThings to do it.<br>
&gt;<br>
&gt; - Job<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br></div></div></div>