[Haskell-cafe] unsafeDestructiveAssign?

[Alberto G. Corona]

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 <jwlato at 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 <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
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090812/4cf2c6ac/attachment.html