[Haskell-cafe] unsafeDestructiveAssign?

[John Meacham]

On Wed, Aug 12, 2009 at 06:48:33PM +0100, John Lato wrote:
> On Wed, Aug 12, 2009 at 2:39 PM, Derek Elkins<derek.a.elkins at gmail.com> 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/