[Caml-list] Re: Constants immediatelly disappear from the Weak array. (PR#1925)

[Caml-list] Re: Constants immediatelly disappear from the Weak array. (PR#1925)

[Damien Doligez]

On Wednesday, November 12, 2003, at 10:13 AM, Aleksey Nogin wrote:

> When trying to switch from 3.06 to 3.07+2 I've noticed the following 
> difference in how the Weak module works:

[
   In 3.06, an empty list [] does not disappear from a weak array;
   in 3.07+2 it disappears immediately
]

> Basically, in 3.07+2, the empty list disappears from the weak array as 
> soon as it is added into it. Is this a bug or a feature?

Feature.


> The old behavior is useful because it allows to assume that while a 
> value is referenced somewhere, Weak.get will always return Some. This 
> allowed using Weak.get as an indicator of whether it was OK to discard 
> some "helper" data (which should be only discarded after the primary 
> data is no longer in use).

Yes, but.  In 3.06, [] will never be removed from the weak array, and
you will keep your helper data forever.

The source your the problem is that [] is not allocated in the heap.
It is represented by an integer value.  Hence, there is no sharing
between various occurrences of [] in your data and the notion of a
weak pointer to [] does not make sense.

If you really want to make sure that you are manipulating pointers,
you should use a record or a list ref.

-- Damien

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] Re: Constants immediatelly disappear from the Weak array. (PR#1925)

[Aleksey Nogin]

On 12.11.2003 04:49, Damien Doligez wrote:

> Yes, but.  In 3.06, [] will never be removed from the weak array, and
> you will keep your helper data forever.

But that is reasonable semantically - since for all we know some 
reachable memory location can have [] in it, so we need to keep it 
forever. Note that for the same reason the helper data needs to stay 
around forever _anyway_, but now the implementation just got _much_ uglier.

Basically, we used to have a very nice and completely polymorphic 
weak_memo module (that solves the following problem - if you have an 
arbitrary mutually-recursive data type that you are converting into an 
"isomorphic" one, how do you set it up so that equal inputs are mapped 
to the same output, and the whole process takes linear time); and in 
3.07 this module needs to include various calls to Obj to be able to 
figure out whether the output happens to be an unboxed value.

In other words, 3.06 allowed things to stay completely polymorphic, 
while 3.07 requires Obj hacks. Very unfortunate...

-- 
Aleksey Nogin

Home Page: http://nogin.org/
E-Mail: nogin@cs.caltech.edu (office), aleksey@nogin.org (personal)
Office: Jorgensen 70, tel: (626) 395-2907

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners