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 concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id B8DBEBB94 for ; Mon, 3 Oct 2005 23:29:02 +0200 (CEST) Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j93LT1hK018952 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 3 Oct 2005 23:29:02 +0200 Received: from [80.229.56.224] (helo=chetara) by ptb-relay01.plus.net with esmtp (Exim) id 1EMXrn-0007g8-7B for caml-list@yquem.inria.fr; Mon, 03 Oct 2005 22:28:59 +0100 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: Ant: Re: Ant: Re: Ant: Re: [Caml-list] Avoiding shared data Date: Mon, 3 Oct 2005 22:08:34 +0100 User-Agent: KMail/1.7.2 References: <20051003200337.14092.qmail@web26809.mail.ukl.yahoo.com> In-Reply-To: <20051003200337.14092.qmail@web26809.mail.ukl.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510032208.35273.jon@ffconsultancy.com> X-Miltered: at concorde with ID 4341A29D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 avoiding:01 stack:01 recursive:01 stack:01 avoiding:01 pointers:01 arrays:01 ocaml:01 unions:01 haskell:01 suboptimal:01 ocaml:01 frog:98 wrote:01 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=none autolearn=disabled version=3.0.3 On Monday 03 October 2005 21:03, Martin Chabr wrote: > what I am especially concerned about is the stack > overflow for non-tail-recursive programs. Speed is of > less importance. Yes. Many useful algorithms are non-tail recursive and do not cause stack overflows, e.g. those that recurse O(log n) times. > By the way, we are diverting from the subject of this > thread and from the main cause of my concern: > > 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? In other > words, who wants to have an array or a list of > pointers which are pointing to the same thing? If you mean this: # let a = Array.make 3 (ref 0) in (a.(0) := 3; a);; - : int ref array = [|{contents = 3}; {contents = 3}; {contents = 3}|] I don't want arrays of elements referencing the same value. So I don't create them. > Does it ever happen in OCaml if programming is done in > a purely functional way? If you mean "is referential transparency useful?" then the answer is definitely yes. I use data structures that share data all the time but not in the form of an array or list of the same repeated value. For example, computing set unions, differences and intersections using the Set module reuses branches of old tree when possible. This reduces the asymptotic algorithmic complexity of these operations so they can run asymptotically faster than imperative implementations. > Does it happen in Haskell? You'll get a suboptimal answer to such questions on this list. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists