Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
vicuna opened this issue Nov 12, 2003 · 2 comments

Comments

@vicuna
Copy link

vicuna commented Nov 12, 2003

Original bug ID: 1927
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)

Bug description

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

@vicuna
Copy link
Author

vicuna commented Nov 14, 2003

Comment author: administrator

On Thursday, November 13, 2003, at 12:22 AM, nogin@cs.caltech.edu wrote:

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.

If I understand correctly, you are describing the hash-consing problem.
I don't see why you need helper data to solve it. Two unboxed values
are (==) if and only if they are (=), so you don't need any sharing
information for unboxed values.

-- Damien

@vicuna
Copy link
Author

vicuna commented Dec 29, 2003

Comment author: administrator

see also #8366 and #8370
wish granted DD 2003-11-20

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant