From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 09FD0BB94 for ; Mon, 3 Oct 2005 22:25:03 +0200 (CEST) Received: from mail.physik.uni-muenchen.de (mail.physik.uni-muenchen.de [192.54.42.129]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id j93KP182006109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 3 Oct 2005 22:25:02 +0200 Received: from localhost (unknown [127.0.0.1]) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id A20C420008; Mon, 3 Oct 2005 22:25:01 +0200 (CEST) Received: from mail.physik.uni-muenchen.de ([127.0.0.1]) by localhost (mail.physik.uni-muenchen.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 07091-02-61; Mon, 3 Oct 2005 22:25:01 +0200 (CEST) Received: from mailhost.cip.physik.uni-muenchen.de (kaiser.cip.physik.uni-muenchen.de [141.84.136.1]) by mail.physik.uni-muenchen.de (Postfix) with ESMTP id 7E01320006; Mon, 3 Oct 2005 22:25:01 +0200 (CEST) Received: from eiger.cip.physik.uni-muenchen.de (eiger.cip.physik.uni-muenchen.de [141.84.136.54]) by mailhost.cip.physik.uni-muenchen.de (Postfix) with ESMTP id 08BD226F4D; Mon, 3 Oct 2005 22:25:01 +0200 (CEST) Received: by eiger.cip.physik.uni-muenchen.de (Postfix, from userid 3092) id A8F5312F75; Mon, 3 Oct 2005 22:25:00 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by eiger.cip.physik.uni-muenchen.de (Postfix) with ESMTP id A494612F17; Mon, 3 Oct 2005 22:25:00 +0200 (CEST) Date: Mon, 3 Oct 2005 22:25:00 +0200 (CEST) From: Thomas Fischbacher To: Martin Chabr Cc: caml-list@yquem.inria.fr Subject: Re: Ant: Re: Ant: Re: Ant: Re: [Caml-list] Avoiding shared data In-Reply-To: <20051003200337.14092.qmail@web26809.mail.ukl.yahoo.com> Message-ID: References: <20051003200337.14092.qmail@web26809.mail.ukl.yahoo.com> X-BOFH: Daemons did it MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: amavisd-new at physik.uni-muenchen.de X-Miltered: at nez-perce with ID 4341939D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 avoiding:01 avoiding:01 pointers:01 nodes:01 semantics:01 2005,:98 cip:98 cip:98 lambda:01 lambda:01 wrote:01 data:02 data:02 debian:02 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=SPF_FAIL autolearn=disabled version=3.0.3 On Mon, 3 Oct 2005, Martin Chabr wrote: > Avoiding shared data. Why is it done that way? Who > wants to have an array or list of identical records or > sub-arrays or other sub-structures which are all > updated at the same time in the same way? Thoughts about substructure updates and sharing structure do not mix. There are situations where the one way to think about things is appropriate, and there are situations when it's the other one. > In other > words, who wants to have an array or a list of > pointers which are pointing to the same thing? Suppose I give you a tree representing the filesystem structure on my machine. Now I ask you to map this to the tree describing the filesystem with one directory renamed and another one (and everythinbg beneath it) deleted. You surely do not want to copy the entire tree, so this is an example where sharing structure perfectly makes sense. And as you do not destructively modify the data in the nodes, it does not matter at all for the semantics of the program that you actually share a lot of data. -- regards, tf@cip.physik.uni-muenchen.de (o_ Thomas Fischbacher - http://www.cip.physik.uni-muenchen.de/~tf //\ (lambda (n) ((lambda (p q r) (p p q r)) (lambda (g x y) V_/_ (if (= x 0) y (g g (- x 1) (* x y)))) n 1)) (Debian GNU)