Re: [Haskell-cafe] unsafeDestructiveAssign?

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/