From: William Smith <bills@emu-bark.com>
To: Caml-list <caml-list@inria.fr>
Subject: [Caml-list] List.fold_left vs. Hashtbl.fold
Date: Thu, 29 Nov 2012 22:06:14 -0500 [thread overview]
Message-ID: <50B822A6.7000504@emu-bark.com> (raw)
That seems like an easy mnemonic--left means the base case argument is on the left and right means that the base case is on the right. This is both for the parameters to fold_left/right and the parameters of its <fun> argument. And then, if there is not _right/_left distinction available for a container, it defaults to being equivalent to _right.
Before I saw other people's explanations, I was thinking about how the parameter order fold_left is more useful for currying.
If you want to create an operator, fold_left makes it a lot easier to curry in its base case and then apply the operator to different lists that the operator is processing last.
If I wanted to do that with fold_right or the other container's folds, I would have to write a wrapper to swap the arguments--which isn't really a big deal, but it's a way that fold_left is more useful that no one mentioned.
Bill
> On Wed, Nov 28, 2012 at 6:25 PM, Gabriel Scherer
> <gabriel.scherer@gmail.com> wrote:
> That's for the type. Regarding the implementation, fold_left applies
> the argument function starting from "the left" (the beginning) of the
> list first, while fold_right begins "on the right" (at the end): for
> some infix operator (++) :
> fold_left (++) init [x; y; z] is ((init ++ x) ++ y) ++ z
> fold_right (++) [x; y; z] init is (x ++ (y ++ (z ++ init)))
> (The evaluation "begins" in the innermost nested parentheses)
On Wed, Nov 28, 2012 at 5:40 AM, William Smith<bills@wwayneb.com> wrote:
> Hashtbl.fold expects the Hasthbl as the second parameter with the 3rd
> parameter being the initial value... just the opposite of List.fold_left.
next reply other threads:[~2012-11-30 3:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-30 3:06 William Smith [this message]
2012-11-30 9:53 ` Gabriel Scherer
2012-11-30 10:06 ` Stefano Zacchiroli
2012-11-30 16:00 ` Gabriel Scherer
2012-11-30 16:48 ` Daniel Bünzli
2012-11-30 11:34 ` Daniel Bünzli
-- strict thread matches above, loose matches on Subject: below --
2012-11-28 4:40 William Smith
2012-11-28 16:17 ` Lukasz Stafiniak
2012-11-28 16:25 ` Malcolm Matalka
2012-11-28 16:21 ` David House
2012-11-29 1:06 ` Francois Berenger
2012-11-28 16:42 ` Oliver Bandel
2012-11-28 17:11 ` Adrien
2012-11-28 17:41 ` Virgile Prevosto
2012-11-29 0:07 ` Jacques Garrigue
[not found] ` <CAPFanBG04BiwJuPkV80__Ondmg1N8OEg4DokiXqDReg3ycNBdA@mail.gmail.com>
2012-11-28 17:25 ` Gabriel Scherer
2012-11-28 17:37 ` Lukasz Stafiniak
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=50B822A6.7000504@emu-bark.com \
--to=bills@emu-bark.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).