From: Xavier Leroy <xleroy@pauillac.inria.fr>
To: Juan Jose Garcia Ripoll <jjgarcia@ind-cr.uclm.es>,
Caml list <caml-list@pauillac.inria.fr>
Subject: Re: Map is not tail recursive
Date: Mon, 11 Jan 1999 12:03:58 +0100 [thread overview]
Message-ID: <19990111120358.25340@pauillac.inria.fr> (raw)
In-Reply-To: <369885D1.1C8A1269@ind-cr.uclm.es>; from Juan Jose Garcia Ripoll on Sun, Jan 10, 1999 at 11:49:53AM +0100
> I've had a look at the List package and it seems that it is not properly
> tail recursive.
No, it is not. Like many other functions on lists.
> Even more, for medium to large lists it exhausts the
> stack. I would suggest either recoding it as
> [with List.reverse]
> Another possibility would be to introduce destructive operations such as
> Scheme's setcdr! and setcar!. This would eliminate the need of using
> List.reverse, at the cost of introducing some imperative style.
The solution using List.reverse has unacceptable run-time penalty. In
particular, it heap-allocates twice as much than the natural
implementation.
setcdr! for lists is not available in the language, since lists are
immutable. The underlying implementation model supports setcdr!
(at some cost, though, because of the generational garbage
collection), so we could have a "magic" implementation of List.map
that uses setcdr!, but it's always preferable to remain within what
the language can express.
Let me put this another way. There are some library functions for
which no "one size fits all" implementation exist: i.e. the
implementation favors one style of use over others. For List.map or
list concatenation, for instance, one has to choose between running at
full speed on small to medium-sized lists, or being tail-recursive and
handling arbitrarily large lists at a significant cost in speed and
clarity of implementation. I chose the former approach. So, if you
really need to handle large lists, you may have to write your own
(tail-rec and slow) map function. It's not really code duplication,
in that your map function will have quite different running behavior
than the one in the standard library.
I would also contend that if your program routinely manipulate
100000-element lists, then you're probably using the wrong data
structure anyway. But that's a different issue.
Regards,
- Xavier Leroy
next prev parent reply other threads:[~1999-01-12 9:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-01-10 10:49 Juan Jose Garcia Ripoll
1999-01-11 11:03 ` Xavier Leroy [this message]
1999-01-12 11:49 ` William Chesters
1999-01-11 18:51 David McClain
1999-01-13 8:47 ` Jacques GARRIGUE
1999-01-12 12:06 Marc Rouaix
1999-01-13 17:40 Marc Rouaix
1999-01-14 3:49 David McClain
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=19990111120358.25340@pauillac.inria.fr \
--to=xleroy@pauillac.inria.fr \
--cc=caml-list@pauillac.inria.fr \
--cc=jjgarcia@ind-cr.uclm.es \
/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).