[Haskell-cafe] Re: unsafeDestructiveAssign?

[John Lato]

>  From: John Meacham <john at repetae.net>
>  Subject: 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<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,

Thanks for this clear explanation.  The concept of an
unsafeDestructiveAssign function really caught my attention because it
seemed inexpressible.  This makes perfect sense, including an
explanation for mutable data in IO (because IORef, Ptr, and the like
make a "data location" a first class value).

I like to have a solid foundation for my nonsense.

Cheers,
John