Re: [Caml-list] looping recursion

[brogoff <brogoff@speakeasy.net>]

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 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.

I'm not using the terminology with regard to concurrent programming, but simply
saying only I don't need persistence. Maybe I picked up the terminology from
some discussion about versioned arrays (implementing functional arrays on top of
imperative ones) or from Clean.

> Let me just give you a couple eurocents of industrial experience: side-effects
> are utterly bad.

My two U.S. cents of industrial experience is that statement is utterly false.
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 the
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 state.

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 store
some state in one of the calculation, rather than adding an argument to a bunch
of nested functions. Still purely functional to the observer though. What level
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 à 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