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 BAA09942; Fri, 30 Jul 2004 01:40:33 +0200 (MET DST) 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 BAA09710 for ; Fri, 30 Jul 2004 01:40:32 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from alex.baretta.com (host148-4.pool62211.interbusiness.it [62.211.4.148]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i6TNeVEV019705 for ; Fri, 30 Jul 2004 01:40:31 +0200 Received: from baretta.com (unknown [127.0.0.1]) by alex.baretta.com (Postfix) with ESMTP id F209E2D5B90; Thu, 29 Jul 2004 18:42:27 -0400 (EDT) Message-ID: <41097D53.5050607@baretta.com> Date: Fri, 30 Jul 2004 00:42:27 +0200 From: Alex Baretta User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: it, en-us, en MIME-Version: 1.0 To: brogoff Cc: Ocaml Subject: Re: [Caml-list] looping recursion References: <16646.64470.304530.264731@soggy.deldotd.com> <16647.5177.849829.421587@soggy.deldotd.com> <4107544C.4040502@baretta.com> <410898F0.6030804@baretta.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Miltered: at nez-perce with ID 41098AEF.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; baretta:01 baretta:01 caml-list:01 recursion:01 brogoff:01 brogoff:01 catenable:01 deques:01 deques:01 doubly:01 catenable:01 hugely:01 beginners:01 mandated:99 okasaki:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk brogoff wrote: > On Thu, 29 Jul 2004, Alex Baretta wrote: > >>brogoff wrote: > > Some problems are just way easier to solve with imperative programming > though. Have you ever taken a look at purely functional catenable deques? > If you don't need persistence (if your deques are used in a single threaded > manner that is) would you use those instead of the obvious doubly linked > list implementation? That's not an abstract question either, catenable deques > come up quite naturally when implementing some 2D computational geometry > algorithms.I took a look at the latest algorithm by Kaplan and Tarjan and > quickly realized that it was hugely complicated if persistence is not needed. s list: http://groups.yahoo.com/group/ocaml_beginners > I didn't understand the connection between multithreading and persistence, but it's probably too late and I've been working far too much to follow you entirely. Let me just give you a couple eurocents of industrial experience: side-effects are utterly bad. My Xcaml application server was designed two years ago with one major flaw: one global state variable. I'm still fighting with the execution engine to take it away, but that won't happen before a major rewrite. I won't by imperative programming for anything at all. And, yes, in my company the mandated standard for deques is batched queues à la Okasaki. Alex ------------------- 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