caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: brogoff <brogoff@speakeasy.net>
To: Alex Baretta <alex@baretta.com>
Cc: Ocaml <caml-list@inria.fr>
Subject: Re: [Caml-list] looping recursion
Date: Thu, 29 Jul 2004 07:58:37 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.58.0407290715410.22555@shell1.speakeasy.net> (raw)
In-Reply-To: <410898F0.6030804@baretta.com>

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


  reply	other threads:[~2004-07-29 14:58 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-27 23:43 briand
2004-07-28  0:27 ` John Prevost
2004-07-28  0:38   ` John Prevost
2004-07-28  1:17     ` skaller
2004-07-28  1:05   ` briand
2004-07-28  1:43     ` Brian Hurt
2004-07-28  2:49       ` briand
2004-07-28  3:12         ` Brian Hurt
2004-07-28  3:20         ` Brian Hurt
2004-07-28  5:54         ` brogoff
2004-07-28  7:22           ` Alex Baretta
2004-07-28 16:38             ` brogoff
2004-07-28 19:40               ` Jon Harrop
2004-07-28 20:18                 ` Brandon J. Van Every
2004-07-29  6:01                   ` Alex Baretta
2004-07-28 21:22                 ` brogoff
2004-07-29  9:13                   ` Daniel Andor
2004-07-29  9:25                     ` Keith Wansbrough
2004-07-29  9:41                       ` Nicolas Cannasse
2004-07-29  9:57                       ` Xavier Leroy
2004-07-29 10:44                         ` Daniel Andor
2004-07-29 12:56                           ` brogoff
2004-07-29 10:11                     ` skaller
2004-07-29 12:41                     ` brogoff
2004-07-29  6:28               ` Alex Baretta
2004-07-29 14:58                 ` brogoff [this message]
2004-07-29 16:12                   ` Brian Hurt
2004-07-29 17:49                     ` james woodyatt
2004-07-29 19:25                       ` Brian Hurt
2004-07-29 20:01                         ` brogoff
2004-07-30  4:42                           ` james woodyatt
2004-07-29 17:44                   ` james woodyatt
2004-07-29 23:12                     ` skaller
2004-07-29 22:42                   ` Alex Baretta
2004-07-30  2:38                     ` Corey O'Connor
     [not found]                     ` <200407300136.14042.jon@jdh30.plus.com>
2004-07-30 12:45                       ` Alex Baretta
2004-07-30 17:07                     ` brogoff
2004-07-30 18:25                       ` [Caml-list] kaplan-okasaki-tarjan deque (was "looping recursion") james woodyatt
2004-07-30 21:20                         ` brogoff
2004-07-31  5:37                           ` james woodyatt
2004-07-28  7:27       ` [Caml-list] looping recursion skaller
2004-07-28 14:36         ` Brian Hurt
2004-07-28 22:05           ` skaller
2004-07-28  0:37 ` skaller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.58.0407290715410.22555@shell1.speakeasy.net \
    --to=brogoff@speakeasy.net \
    --cc=alex@baretta.com \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).