[Openmcl-devel] memory

[Tim Bradshaw]

On 13 Apr 2010, at 05:04, Gary Byers wrote:

> Feel free to substitute "largely opaque primitive object" for  
> "closure"; I don't
> think that it's uncommon for user-defined data structures to contain  
> primitive
> data structures.  CONSes are "primitive data structures" that aren't  
> exactly
> opaque; HASH-TABLEs are somewhat more opaque (you can enumerate  
> their contents
> via MAPHASH, but HASH-TABLE-SIZE doesn't necessarily reflect the  
> SIZEOF the
> hash table itself), the opacity of closures and functions in CCL  
> depends on
> the platform (and is inherently pretty implementation-dependent) ...

Yes, I thought about that last night after sending my earlier reply...
>
> So ... you could possibly handle these cases if the implementation  
> provided
> some means of enumerating a primitive object's "direct" contents.   
> That's certainly
> doable (and could be useful in other contexts), but using such  
> primitives seems
> to require that the user understand at least some implementation- 
> level concepts
> (even if they don't need to know the details.)  I'm not sure that I  
> understand
> exactly what this means in practice, but I'm not sure that even  
> experienced users
> have (or want, or otherwise need to have) that understanding.


.. and that's more-or-less the problem I came up with.  An  
implementation could, I think, provide some kind of "map-function-over- 
all-the-objects-this-thing-refers-to" function.  But that has at least  
two problems: how does the user of that function know which of these  
objects are ones they already know about and which are genuinely new?  
and, what about objects that something refers to which should be  
genuinely secret (perhaps they're not safe for user code to even refer  
to or something like that)?  I suppose the first of these could be  
solved by user code doing an EQ check (which it will need to do anyway  
to avoid double-counting and loops).  The second I'm not sure about -  
you could include the really-secret stuff in the basic size of the  
object (what SIZEOF) returns, but what if some of that is shared?

I don't think any of this is easy, at all.  It's mostly the same as  
the answer to "why isn't there a general object copier in Lisp?",  
except this is a bit harder.