From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id XAA03251 for caml-red; Mon, 6 Nov 2000 23:23:03 +0100 (MET) 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 UAA10489 for ; Mon, 6 Nov 2000 20:12:12 +0100 (MET) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id eA6JCBP00356 for ; Mon, 6 Nov 2000 20:12:12 +0100 (MET) Received: from checkerlap.d6.com ([64.160.53.49]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with ESMTP id <0G3M0084U7VVIK@mta6.snfc21.pbi.net> for caml-list@inria.fr; Mon, 6 Nov 2000 10:12:03 -0800 (PST) Date: Mon, 06 Nov 2000 10:15:30 -0800 From: Chris Hecker Subject: Re: practical functional programming In-reply-to: <14854.44822.43851.623717@pc803> X-Sender: def6@shell16.ba.best.com To: Jean-Christophe.Filliatre@lri.fr (Jean-Christophe Filliatre) Cc: caml-list@inria.fr Message-id: <4.3.2.7.2.20001106100700.00c447b0@shell16.ba.best.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Content-type: text/plain; charset="us-ascii" References: <4.3.2.7.2.20001103055229.00ab6880@shell16.ba.best.com> <4.3.2.7.2.20001103055229.00ab6880@shell16.ba.best.com> Sender: weis@pauillac.inria.fr >This is a very silly example but there are many real situations where >persistence is needed (I encountered many of them in practice). That may be a silly example, but it makes a lot of sense to me and I could see making use of that property. I guess my next question then would be related to efficiency: isn't there a lot of copying going on if you've got to make a new instance of your symbol table just to add an element? How does this work out in practice? Again, I'm not saying efficiency is the only metric for software, but it does concern me when I see a large datastructure copied. Is there some sort of reference counted sharing going on, or are there actually two copies of the data in memory if you wrote your example in caml? I guess my hope would be that in the case where you didn't reference the old datastructure ever again you would get performance close to the equivalent imperative datastructure. In the case where you did reference both old and new you'd get performance similar to writing an "undo-able" imperative datastructure from scratch, possibly with an optimization for not accessing the old datastructure until the new one had been undone (like in your example, and I would assume that's the common case for using persistence). Chris