derek.a.elkins at gmail.com
Wed Aug 12 09:39:56 EDT 2009
On Wed, Aug 12, 2009 at 4:41 AM, John Lato<jwlato at 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
> 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...
>> From: Job Vranish <jvranish at 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
>> 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.
More information about the Haskell-Cafe