[Haskell-cafe] unsafeDestructiveAssign?

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