but without that function, stable names are not that useful I guess? they would cause a space leak? On Mon, Aug 31, 2009 at 10:59 PM, Job Vranish wrote:

I also would like a isStableNameTargetAlive function. Though if you had such a function then you probably _could_ make a deRefStableName function, which, since there isn't one, probably means that such a function would be hard to make.

- Job

On Sun, Aug 30, 2009 at 4:54 PM, Peter Verswyvelen wrote:

...

...

From the documentation, I don't think I grasp how stable names work. From the docs: "There is no deRefStableName operation. You can't get back from a stable name to the original Haskell object. The reason for this is that the existence of a stable name for an object does not guarantee the existence of the object itself; it can still be garbage collected."

From this I can conclude that stable names behave a bit like weak pointers.

However, suppose I have a hash table of these stable names. How can I remove the redundant stable names from the table? I mean removing stable names that refer to an object that is garbage collected? I don't see any function for checking that (e.g. isStableNameTargetAlive or something)

Thanks, Peter

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

I was planning to use them for caching OpenGL display lists and render targets. These are generated from a pure scene graph description, and if the same description is handed over to the render engine, it would just reuse the previously cached OpenGL object. I can of course just embedding and IORef inside the pure structures, that would also work I guess On Tue, Sep 1, 2009 at 6:09 PM, Job Vranish wrote:

Well usually, when I've used stable names, I've just used them to check if things are the same, and then thrown them away. So no chance for a space leak. It's usually unsafe to keep stable names around for very long as they can lose their ability to tell if two things are the same (if this surprises you, you should carefully reread http://haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-StableName... ).

Out of curiosity, how are you planning on using them?

- Job

On Tue, Sep 1, 2009 at 3:40 AM, Peter Verswyvelen wrote:

...

but without that function, stable names are not that useful I guess? they would cause a space leak? On Mon, Aug 31, 2009 at 10:59 PM, Job Vranish wrote:

...

I also would like a isStableNameTargetAlive function. Though if you had such a function then you probably _could_ make a deRefStableName function, which, since there isn't one, probably means that such a function would be hard to make.

- Job

On Sun, Aug 30, 2009 at 4:54 PM, Peter Verswyvelen wrote:

...

...

From the documentation, I don't think I grasp how stable names work. From the docs: "There is no deRefStableName operation. You can't get back from a stable name to the original Haskell object. The reason for this is that the existence of a stable name for an object does not guarantee the existence of the object itself; it can still be garbage collected." From this I can conclude that stable names behave a bit like weak pointers. However, suppose I have a hash table of these stable names. How can I remove the redundant stable names from the table? I mean removing stable names that refer to an object that is garbage collected? I don't see any function for checking that (e.g. isStableNameTargetAlive or something) Thanks, Peter

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

Yes that is possible too. But it feels "obvious" to first lookup by stable name. I had no idea stable names were so volatile. They should be called unstable names then :-) In .NET it is possible to assign an identifier to an object, and that identifier will always be the same for the same object, no matter where to garbage collectors moves the object in memory. For Haskell, at first sight it would feel natural to have something like that too. On Tue, Sep 1, 2009 at 8:31 PM, Luke Palmer wrote:

Have you considered computing a hash of the scene graph description (compositionally)?  This gives you all the same advantages, including re-using shared subparts of the graph (which would be unlikely to stay around for very long as stable names).

Luke

On Tue, Sep 1, 2009 at 11:02 AM, Peter Verswyvelen wrote:

...

I was planning to use them for caching OpenGL display lists and render targets. These are generated from a pure scene graph description, and if the same description is handed over to the render engine, it would just reuse the previously cached OpenGL object.  I can of course just embedding and IORef inside the pure structures, that would also work I guess

On Tue, Sep 1, 2009 at 6:09 PM, Job Vranish wrote:

...

Well usually, when I've used stable names, I've just used them to check if things are the same, and then thrown them away. So no chance for a space leak. It's usually unsafe to keep stable names around for very long as they can lose their ability to tell if two things are the same (if this surprises you, you should carefully reread http://haskell.org/ghc/docs/latest/html/libraries/base/System-Mem-StableName... ).

Out of curiosity, how are you planning on using them?

...

- Job

On Tue, Sep 1, 2009 at 3:40 AM, Peter Verswyvelen wrote:

...

but without that function, stable names are not that useful I guess? they would cause a space leak? On Mon, Aug 31, 2009 at 10:59 PM, Job Vranish wrote:

...

I also would like a isStableNameTargetAlive function. Though if you had such a function then you probably _could_ make a deRefStableName function, which, since there isn't one, probably means that such a function would be hard to make.

- Job

On Sun, Aug 30, 2009 at 4:54 PM, Peter Verswyvelen wrote:

...

>From the documentation, I don't think I grasp how stable names work. From the docs: "There is no deRefStableName operation. You can't get back from a stable name to the original Haskell object. The reason for this is that the existence of a stable name for an object does not guarantee the existence of the object itself; it can still be garbage collected." From this I can conclude that stable names behave a bit like weak pointers. However, suppose I have a hash table of these stable names. How can I remove the redundant stable names from the table? I mean removing stable names that refer to an object that is garbage collected? I don't see any function for checking that (e.g. isStableNameTargetAlive or something) Thanks, Peter

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

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

A monad can surely handle this, but then this is purely for caching, and enforcing a monad just for getting caching sounds like overkill. Caching is something you typically add in the end, and using a monad for that seems akward no? Since all "objects" in Haskell are readonly, it looks line an ideal opportunity to associate a cached object with another object without needing to wrap a lot of code in a monad On Wed, Sep 2, 2009 at 1:25 AM, Brandon S. Allbery KF8NH wrote:

On Sep 1, 2009, at 14:57 , Peter Verswyvelen wrote:

...

In .NET it is possible to assign an identifier to an object, and that identifier will always be the same for the same object, no matter where to garbage collectors moves the object in memory. For Haskell, at first sight it would feel natural to have something like that too.

Hm. I'd think such names would have to live in a monad (which then leads you to either Reader or ST, I think).

-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university    KF8NH