Alberto G. Corona
agocorona at gmail.com
Wed Aug 12 06:06:20 EDT 2009
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
> 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
> > 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
> > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe