[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"]


More information about the Haskell-Cafe mailing list