From: Martin Jambon <martin.jambon@ens-lyon.org>
To: Anthony Tavener <anthony.tavener@gmail.com>
Cc: Yaron Minsky <yminsky@janestreet.com>,
"caml-list@inria.fr" <caml-list@inria.fr>,
Shuai Wang <wangshuai901@gmail.com>
Subject: Re: [Caml-list] Why List.map does not be implemented tail-recursively?
Date: Sun, 28 Sep 2014 22:40:47 -0700 [thread overview]
Message-ID: <5428F0DF.9090400@ens-lyon.org> (raw)
In-Reply-To: <CAN=ouMQODYEGrwT1hmLkAxzvA+CWMknUEgLks-myHonDDavqKw@mail.gmail.com>
On Sun 28 Sep 2014 09:09:48 PM PDT, Anthony Tavener wrote:
> A remark about the "reverse" list operations... I find that it often
> turns out that I'll have an even number of these reverse operations.
> So even if I need to maintain the final list order, it can be for free.
>
> For example, List.rev_map, followed by a List.rev_append... everything
> is tail-recursive without adding extra list-reversals, and the final
> order is maintained.
I also was obsessed with this when I started using OCaml a long time
ago and was worried that list operations would double the cost of my
algorithms (do the math: this is not how it works).
Unfortunately the practice obfuscates the source code. It makes it
tricky to add or remove an operation in the chain, and overall it's an
unnecessary cognitive burden for anyone reading the code. These
optimizations should be done outside of the application code, either in
the list library or by the compiler; most of the time they are
absolutely needless anyway.
Martin
> On Sun, Sep 28, 2014 at 8:31 PM, Shuai Wang <wangshuai901@gmail.com
> <mailto:wangshuai901@gmail.com>> wrote:
>
> Wow, List.rev_map f (List.rev li) looks very elegant, thank you
> all for the helpful materials! I should definitely try Core lib soon.
>
> I have been working on a binary program analysis project for over
> half a year in OCaml, and it is really enjoyable to write OCaml code!
> hope I can open source the analysis tool eventually and contribute
> to the community :)
>
> Best,
> Shuai
>
>
>
> On Sun, Sep 28, 2014 at 4:26 PM, Yaron Minsky
> <yminsky@janestreet.com <mailto:yminsky@janestreet.com>> wrote:
>
> Indeed, the implementation from that post did make it into
> Core_kernel. Here's the link:
>
> https://github.com/janestreet/core_kernel/blob/release-112.01.00/lib/core_list.ml#L380
>
> y
>
> On Sun, Sep 28, 2014 at 3:45 PM, Malcolm Matalka
> <mmatalka@gmail.com <mailto:mmatalka@gmail.com>> wrote:
> > https://blogs.janestreet.com/optimizing-list-map/
> >
> > And from the horse's mouth:
> >
> >
> https://groups.google.com/forum/#!msg/fa.caml/YaLYqkpn928/1jdo8a0K6AEJ
> >
> > Shuai Wang <wangshuai901@gmail.com
> <mailto:wangshuai901@gmail.com>> writes:
> >
> >> Hello list,
> >>
> >>
> >> I am working on some stack_overflow exception in our recent
> project written
> >> in OCaml
> >> and eventually it turns out that this exception is thrown
> by List.map
> >> function.
> >>
> >> By seeing the source code of OCaml's List module
> >>
> <https://code.ohloh.net/file?fid=P5Us_txNCMHIhpdfML6OZ8QN4Zs&cid=Jigg8RAfQdg&s=ocaml%20list.ml&pp=0&fp=305967&fe=ml&ff=1&filterChecked=true&mp=1&ml=1&me=1&md=1#L3>,
> >> it seems that map function
> >> does not be implemented tail-recursively:
> >>
> >> let rec map f = function
> >> [] -> []
> >> | a::l -> let r = f a in r :: map f l
> >>
> >>
> >>
> >> So my question is:
> >>
> >> *Why would OCaml's implementation List.map like this? *
> >>
> >> In my humble option, it definitely should be written in a
> tail-recursive
> >> way,
> >> and it not, stack_overflow would be unavoidable.
> >> For example in order to handle the exception,
> >> I abandon the code using List.map and rewrite it into a
> tail-recursive help
> >> function.
> >>
> >> Best,
> >> Shuai
> >
> > --
> > Caml-list mailing list. Subscription management and archives:
> >https://sympa.inria.fr/sympa/arc/caml-list
> > Beginner's list:http://groups.yahoo.com/group/ocaml_beginners
> > Bug reports:http://caml.inria.fr/bin/caml-bugs
>
>
>
next prev parent reply other threads:[~2014-09-29 5:40 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-28 19:28 Shuai Wang
2014-09-28 19:45 ` Malcolm Matalka
2014-09-28 20:26 ` Yaron Minsky
2014-09-29 2:31 ` Shuai Wang
2014-09-29 4:09 ` Anthony Tavener
2014-09-29 5:40 ` Martin Jambon [this message]
2014-09-29 9:13 ` Erkki Seppala
2014-09-29 9:15 ` Erkki Seppala
2014-09-28 19:31 Shuai Wang
2014-09-28 19:36 ` Gabriel Scherer
2014-09-28 19:45 ` Anthony Tavener
2014-09-29 12:08 ` Goswin von Brederlow
2014-09-29 14:02 ` Pierre Chambart
2014-09-29 15:44 ` Yaron Minsky
2014-09-29 21:00 ` Gabriel Scherer
2014-10-02 10:09 ` Stephen Dolan
2015-06-01 12:02 ` Jon Harrop
2015-06-02 12:04 ` Stephen Dolan
2015-06-05 10:21 ` Goswin von Brederlow
2014-09-30 6:29 ` Goswin von Brederlow
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=5428F0DF.9090400@ens-lyon.org \
--to=martin.jambon@ens-lyon.org \
--cc=anthony.tavener@gmail.com \
--cc=caml-list@inria.fr \
--cc=wangshuai901@gmail.com \
--cc=yminsky@janestreet.com \
/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