On Sat, 30 Aug 2008, Ashley Yakeley wrote:

Ganesh Sittampalam wrote:
Every single call to newIORef, across the whole world, returns a different ref.

How do you know? How can you compare them, except in the same Haskell expression?

I can write to one and see if the other changes.

The "same" one as a previous one can only be returned once the old one has become unused (and GCed).

Perhaps, but internally the IORef is a pointer value, and those pointer values might be the same. From the same perspective, one could say that

How can they be the same unless the memory management system is broken? I consider different pointers on different machines or in different virtual address spaces different too; it's the fact that they don't alias that matters.

every single call to newUnique across the whole world returns a different value, but internally they are Integers that might repeat.

The thing about pointers is that they are managed by the standard behaviour of memory allocation. This isn't true of Integers.

In fact this point suggests an implementation for Data.Unique that should actually be safe without global variables: just use IORefs for the actual Unique values. IORefs already support Eq, as it happens. That gives you process scope for free, and if you want bigger scopes you can pair that with whatever makes sense, e.g. process ID, MAC address, etc.

Two IO executions are in the same "global scope" if their resulting values can be used in the same expression. Top-level <- declarations must execute at most once in this scope.

This brings us back to the RPC question, and indeed to just passing values to somewhere else via FFI. I think you can work around some of that by talking about ADTs that aren't serialisable (e.g. ban the class Storable), but now we have different global scopes for different kinds of values, so which scope do we use to define <- ?

Ganesh
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to