IMHO (and only IMHO) 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 !. 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. In a impure context, use IORefs. 2009/8/12 John Lato

Hi Job,

I don't think this hypothetical function could exist; you may as well call it "notEverSafeOhTheHumanity" and be done with it.

Since Haskell provides no guarantees about when (if ever) any given function/data will be evaluated, you would need some mechanism to tell the compiler that a data chunk has a certain value at one time and a different value at another. The language provides this in the IO (and ST) monads. So the function would need to live within IO, and you don't gain anything. If you try to take it outside of IO, with e.g. unsafePerformIO, then the compiler will no longer treat it like IO and the result is free to be evaluated whenever, so you're back where you started.

Also, keep in mind that purity is a language requirement in Haskell and such a function really would "break everything". Specifically, you would get differing output depending on the exact transformations performed by the compiler, which in general would be difficult to predict in advance, probably not the same between different compiler versions, changed by compiler flags and phases of the moon, etc. I have an example in a darcs repo somewhere...

Cheers, John

...

From: Job Vranish Subject: Re: [Haskell-cafe] unsafeDestructiveAssign?

Ga! Before to many people start flooding me responses of "This is really dumb idea don't do it!" I would like to clarify that for the most part IKnowWhatI'mDoing(TM)

I am well aware of the usual ST/IORefs as the usual solutions to data mutability in haskell. I very very much understand purity, and why it is a good thing, and why we should try to stay away from IO and ST as much as possible. I am very much away that even if I had such a function that it will probably break everything. I am not just trying to make things run faster.

What I am trying to do is hyper unusual and I really do need an unsafeHorribleThings to do it.

- Job

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe