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

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
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
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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Wed, Aug 12, 2009 at 4:41 AM, 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
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.

On Wed, Aug 12, 2009 at 2:39 PM, Derek Elkins
(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.
Lennart is right of course, but wouldn't his example just be a specific case of my argument? That is, the compiler decided to evaluate the data at compile time by replacing it with the primitive value and inlining it? It seems to me that in the absence of putting some scope or sequencing upon the mutating function, there's no way for such an unsafeMutate* to have any defined meaning in Haskell. And once you have provided either scope or evaluation order, it would be equivalent to just using a monad (although not necessarily IO). Which leads to the point I really want to make. Would a monad other than IO be acceptable? You could provide this functionality with a Reader's 'local' function for example, or with State. Cheers, John

On Wed, Aug 12, 2009 at 06:48:33PM +0100, John Lato wrote:
On Wed, Aug 12, 2009 at 2:39 PM, Derek Elkins
wrote: (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.
Lennart is right of course, but wouldn't his example just be a specific case of my argument? That is, the compiler decided to evaluate the data at compile time by replacing it with the primitive value and inlining it? It seems to me that in the absence of putting some scope or sequencing upon the mutating function, there's no way for such an unsafeMutate* to have any defined meaning in Haskell. And once you have provided either scope or evaluation order, it would be equivalent to just using a monad (although not necessarily IO).
The inherent problem is that 'heap locations' are not first class values in haskell. There is no way to refer to 'the location holding a variable', not so much because they don't exist, but because it is just inexpressible in haskell. for instance, let b = a in unsafeUpdate b 3 what exactly does this update? Is there any meaningful interpretation of it? b and a are the same value, but that says nothing about the heap location. or
f x = unsafeUpdate x 10
are you updating the argument to f or what was passed into f? the above will likely be translated internally by the compiler to something like:
void f(int x) { x = 10; }
which is obviously a nop. the inherent problem is that variables don't refer to heap locations, they refer to values and pretty much all compiler transforms depend on that. This has nothing to do with monads, there is no monad that will change that feature of haskell: I don't think it would be a rare thing for 'unsafeupdate' to not work, I would expect it to pretty much never do what you want with a modern compiler, it would break eta reduction and beta reduction for instance, which are the bread and butter of compiler transforms. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
participants (4)
-
Alberto G. Corona
-
Derek Elkins
-
John Lato
-
John Meacham