From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id AAA16214; Thu, 13 Nov 2003 00:22:08 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id AAA16667 for ; Thu, 13 Nov 2003 00:22:07 +0100 (MET) Received: from swordfish.cs.caltech.edu (swordfish.cs.caltech.edu [131.215.44.124]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id hACNM6122701; Thu, 13 Nov 2003 00:22:06 +0100 (MET) Received: from cs.caltech.edu (wasco.cs.caltech.edu [131.215.44.173]) by swordfish.cs.caltech.edu (Postfix) with ESMTP id 6C74DDF265; Wed, 12 Nov 2003 15:22:05 -0800 (PST) Message-ID: <3FB2C09D.3050208@cs.caltech.edu> Date: Wed, 12 Nov 2003 15:22:05 -0800 From: Aleksey Nogin Organization: California Institute of Technology, Computer Science Department User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Damien Doligez Cc: caml-list@inria.fr, caml-bugs@pauillac.inria.fr Subject: Re: [Caml-list] Re: Constants immediatelly disappear from the Weak array. (PR#1925) References: <9969407E-150E-11D8-AD29-00039310CAE8@inria.fr> In-Reply-To: <9969407E-150E-11D8-AD29-00039310CAE8@inria.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 constants:01 damien:01 3.06,:01 helper:01 semantically:01 helper:01 uglier:01 memo:01 isomorphic:01 3.07:01 unboxed:01 3.06:01 3.07:01 hacks:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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