On Wed, Aug 12, 2009 at 4:41 AM, John Lato<jwl...@gmail.com> wrote: > 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
(To Alberto as well.) Unsurprisingly, Lennart stated the real issue, but I'll re-emphasize it. As much trouble as such a profound violation of purity would cause, it's not the biggest problem. If that were all, you could easily write a C/assembly function that would do what was desired. The real problem is that there isn't necessarily any "data chunk" at all, i.e. there may not be anything to mutate. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
