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 <jwl...@gmail.com> > 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 <jvran...@gmail.com> > > 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 >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
