caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
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.

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