[Haskell-cafe] unsafeDestructiveAssign?

[Derek Elkins]

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
> 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 <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
>> 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.