[Haskell-cafe] Re: [Haskell] Top Level <-
Ganesh Sittampalam
ganesh at earth.li
Sat Aug 30 09:30:36 EDT 2008
On Sat, 30 Aug 2008, Ashley Yakeley wrote:
> Ganesh Sittampalam wrote:
>> Firstly, that's a property of the current implementation, rather than a
>> universal one, IMO. I don't for example see why you couldn't add a
>> newIORef variant that points into shared memory, locking issues aside.
>
> OK, so that would be a new Haskell feature. And it's that feature that
> would be the problem, not top-level <-. It would bring its own garbage
> collection issues, for instance.
OK, never mind about that; I agree it's not a very good idea. An IORef
shouldn't escape the scope of the RTS/GC that created it.
>> Also, the issue is not whether you can *use* them across multiple
>> processes, but whether they are unique across multiple processes.
>> Uniqueness has two possible definitions; aliasing, and representational
>> equality. No two IORefs will ever alias, so by that definition they exist
>> at global scope. For representational equality, that exists at least at
>> process scope, and perhaps more.
>
> By global scope, I mean the largest execution scope an IORef created by
> newIORef can have. Each top-level IORef declaration should create an IORef
> at most once in this scope.
That's a reasonable definition, if by "execution scope" you mean your
previous definition of "where the IORef can be directly used". But it's
not process scope; two independent Haskell libraries in the same process
can no more share IORefs than two separate Haskell processes.
[what I meant by global scope above was "the entire world"]
Ganesh
More information about the Haskell-Cafe
mailing list