On Thu, 29 Jul 2004, Alex Baretta wrote:
> brogoff wrote:
> > Well, I'm still on the caml-list, so of course it isn't *that* bad. Also, as
> > I said, if you need a tail recursive map over built in lists, you have at
> > least two options. Unfortunately, my preference is to use Obj, which IMO
> > points to a deficiency in the core language. Most, maybe all, of my issues
> > with OCaml, amount to petty complaints, no showstoppers or dealbreakers.
> > Hey, at least I'm not whining about the license!
>
> Yes, I guess we simply can live with it. I can't wait to have STL
> iterators in Ocaml, but meanwhile I can live with this functional
> nonsense: lists, maps, sets... ;)

That's funny! I used to get chided by the guy who hired me for being a
bit of a functional snob, always trying to find a side effect free solution
(BTW, the "mutable" lists using Obj are side effect free) instead of solving
every problem with a hash table :-)

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.

>
> > There are quite a few cases where singly linked lists are the most efficient
> > data structure, and they're just right for the problem. Streams and laziness
> > are  not at all efficient in comparison. Stack overflow commonly happens whenm
> > one of my users (yup, I have users of my code who aren't me ;-) decides to
> > run on data much larger than I'd anticipated.
>
> Huge lists are usually not an efficient data structure.

Sure, but sometimes you have programs which aren't intended to be used on huge
data sets, but pesky users aren't deterred by your warnings. So, even if the
extremely common case is not huge, it shouldn't fail in the huge case, unless of
course the failure is Out_of_memory.

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