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 TAA28500; Fri, 30 Jul 2004 19:07:21 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA28841 for ; Fri, 30 Jul 2004 19:07:20 +0200 (MET DST) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i6UH7ISH024144 for ; Fri, 30 Jul 2004 19:07:19 +0200 Received: (qmail 8658 invoked from network); 30 Jul 2004 17:07:17 -0000 Received: from shell2.speakeasy.net ([69.17.110.71]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 30 Jul 2004 17:07:17 -0000 Date: Fri, 30 Jul 2004 10:07:17 -0700 (PDT) From: brogoff To: Alex Baretta cc: Ocaml Subject: Re: [Caml-list] looping recursion In-Reply-To: <41097D53.5050607@baretta.com> Message-ID: References: <16646.64470.304530.264731@soggy.deldotd.com> <16647.5177.849829.421587@soggy.deldotd.com> <4107544C.4040502@baretta.com> <410898F0.6030804@baretta.com> <41097D53.5050607@baretta.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Miltered: at concorde with ID 410A8046.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; brogoff:01 brogoff:01 caml-list:01 recursion:01 baretta:01 baretta:01 catenable:01 deques:01 deques:01 doubly:01 catenable:01 hugely:01 beginners:01 versioned:01 flamewar:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, 30 Jul 2004, Alex Baretta wrote: > 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 deque= s? > > If you don't need persistence (if your deques are used in a single thre= aded > > manner that is) would you use those instead of the obvious doubly linke= d > > list implementation? That's not an abstract question either, catenable = deques > > come up quite naturally when implementing some 2D computational geometr= y > > algorithms.I took a look at the latest algorithm by Kaplan and Tarjan a= nd > > quickly realized that it was hugely complicated if persistence is not n= eeded. > 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. I'm not using the terminology with regard to concurrent programming, but si= mply saying only I don't need persistence. Maybe I picked up the terminology fro= m some discussion about versioned arrays (implementing functional arrays on t= op of imperative ones) or from Clean. > Let me just give you a couple eurocents of industrial experience: side-ef= fects > are utterly bad. My two U.S. cents of industrial experience is that statement is utterly fal= se. Side effects are to be controlled and dealt with, but they are unavoidable. But I don't feel like having a flamewar about it, no doubt we've all seen t= he arguments and no one will offer anything new... > My Xcaml > application server was designed two years ago with one major flaw: one > global state variable. Sure, Dante's lowest level of Hell is reserved for those who abuse global s= tate. Ever look at the purely functional red black tree implementation in the SML= /NJ utils library? Last time I looked, the author used a local reference to sto= re some state in one of the calculation, rather than adding an argument to a b= unch of nested functions. Still purely functional to the observer though. What l= evel of Hell should he go to? > 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. Even monadic IO strikes me as imperative, so if you have IO, there's really= no way to avoid it. > And, yes, in my company the > mandated standard for deques is batched queues =E0 la Okasaki. I think of the respondents to my point about catenable deques, only James Woodyatt seems to get what I mean. And given the fact that persistence is not necessary in my application, I am willing to exercise extra care to get that annoying imperative code right. I would like to see an implementation of the catenable deques only using simple list ops (not laziness) described by Kaplan and Tarjan, in OCaml. If I remember, the algorithm was described using nonuniform data types, so that's yet another plug for supporting this more directly in OCaml, meaning, without having to use recursive modules, record field polymorphism, or polymorphic records to work around the ability to directly write such functions. -- Brian ------------------- 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