Re: [Haskell-cafe] Weak pointers and referential transparency???
Brian Hulley wrote: > [EMAIL PROTECTED] wrote: [...] > > My reading of the semantics > > (http://haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-Weak.html#4) > > is that you can be sure the proxy *object* is gone. > > My problem is that I don't know what to make of the word > "object" in the context of Haskell ie when can I be sure > that a value is actually being represented as a pointer > to a block of memory and not stored in registers or > optimized out? Or is the compiler clever enough to > preserve the concept of "object" despite such > optimizations? I had been designing my Model/Proxy data > types with the Java notion of "everything is a pointer to > an object" but is this always correct relative to Haskell > as a language or is it just a consequence of the current > GHC implementation? In the context of System.Mem.Weak, but not necessarily GHC, we're concerned solely with garbage collection of heap objects. So yes, that's Java-like. AFAIK. An example of something outside that context is a GHC Int# (unboxed Int). It never inhabits the heap, and isn't allowed to be passed to a function where a polymorphic parameter is expected (such as mkWeak). Regards, Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Weak pointers and referential transparency???
[EMAIL PROTECTED] wrote: Brian Hulley wrote: [...] Ref.write proxiesRef $! (weakProxy : proxies) (This is nothing to do with your main question, but the strict application looks unnecessary there. Its right hand side is already a constructor cell.) Yes, thanks for pointing this out. [...] In other words, if the entry for the proxy in the table stored in the Model dies, can I be absolutely 100% sure that this means the proxy no longer exists in any shape or form in the running program? My reading of the semantics (http://haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-Weak.html#4) is that you can be sure the proxy *object* is gone. My problem is that I don't know what to make of the word "object" in the context of Haskell ie when can I be sure that a value is actually being represented as a pointer to a block of memory and not stored in registers or optimized out? Or is the compiler clever enough to preserve the concept of "object" despite such optimizations? I had been designing my Model/Proxy data types with the Java notion of "everything is a pointer to an object" but is this always correct relative to Haskell as a language or is it just a consequence of the current GHC implementation? As for referential transparency... Fan-in: If you create equivalent proxies in different calls to createProxy, it's possible that they'll end up referring to the same object (e.g. if the compiler or RTS does something fancy, or you use a memoised smart constructor). So then a single live proxy object *could* protect many elements of your Weak Proxy list from scavenging. Fan-out: It would seem perverse to cry "referential transparency!" and spontaneously clone one of your proxy objects. That *could* lead to deRefWeak returning Nothing while an *equivalent* Proxy object is still alive. Might you run your program on an avant-garde distributed RTS? ;-) Someone else might even if I don't! ;-) In the meantime I found a better solution to my original problem without needing to use weak pointers: I now make the proxy pull the changes from the model instead of making the model push them to all registered proxies, so there is no longer any need to have a table of registered proxies hence no need for weak pointers. Thanks, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Weak pointers and referential transparency???
Brian Hulley wrote: [...] > Ref.write proxiesRef $! (weakProxy : proxies) (This is nothing to do with your main question, but the strict application looks unnecessary there. Its right hand side is already a constructor cell.) [...] > In other words, if the entry for the proxy > in the table stored in the Model dies, can > I be absolutely 100% sure that this means > the proxy no longer exists in any shape or > form in the running program? My reading of the semantics (http://haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-Weak.html#4) is that you can be sure the proxy *object* is gone. As for referential transparency... Fan-in: If you create equivalent proxies in different calls to createProxy, it's possible that they'll end up referring to the same object (e.g. if the compiler or RTS does something fancy, or you use a memoised smart constructor). So then a single live proxy object *could* protect many elements of your Weak Proxy list from scavenging. Fan-out: It would seem perverse to cry "referential transparency!" and spontaneously clone one of your proxy objects. That *could* lead to deRefWeak returning Nothing while an *equivalent* Proxy object is still alive. Might you run your program on an avant-garde distributed RTS? ;-) Regards, Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Weak pointers and referential transparency???
Hi,
I have the following data structures:
import System.Mem.Weak
data Proxy = ...
data Model = Model { _proxiesRef :: !(Ref.T [Weak Proxy]), ...}
(Ref.T is just a lifted IORef)
I was writing code like:
createProxy :: MonadIO m => Model -> m Proxy
createProxy Model{_proxiesRef = proxiesRef} = do
proxies <- Ref.read proxiesRef
let
proxy = Proxy{ ... }
weakProxy <- liftIO $ mkWeakPtr proxy Nothing
Ref.write proxiesRef $! (weakProxy : proxies)
return proxy
where the intention is that whenever the returned proxy is no longer used,
the table will no longer hold onto it (the table gets scavenged whenever I
ask for the list of values in it) so there will be no space leak as proxies
are created and discarded.
However when I looked at the above code more closely, it struck me that
Haskell gives no guarantees that the returned proxy is actually the same
object that is referenced by the table, because of referential transparency.
So my question is: will the above code work as expected and is this because
we are allowed to assume non-referential transparency in situations like the
above ie are we allowed to assume that all occurrences of the identifier
"proxy" are always bound to a pointer to the same physical object and that
all other uses of this value in the program are not going to cause it to be
represented by multiple physical objects or otherwise split apart into
registers etc?
In other words, if the entry for the proxy in the table stored in the Model
dies, can I be absolutely 100% sure that this means the proxy no longer
exists in any shape or form in the running program?
Thanks, Brian.
--
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.
http://www.metamilk.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
