From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <bills@emu-bark.com>
X-Original-To: caml-list@sympa.inria.fr
Delivered-To: caml-list@sympa.inria.fr
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by sympa.inria.fr (Postfix) with ESMTPS id 0D3CD7EE1A
	for <caml-list@sympa.inria.fr>; Fri, 30 Nov 2012 04:06:15 +0100 (CET)
Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  bills@emu-bark.com) identity=pra; client-ip=173.201.192.103;
  receiver=mail1-smtp-roc.national.inria.fr;
  envelope-from="bills@emu-bark.com";
  x-sender="bills@emu-bark.com"; x-conformance=sidf_compatible
Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  bills@emu-bark.com) identity=mailfrom;
  client-ip=173.201.192.103;
  receiver=mail1-smtp-roc.national.inria.fr;
  envelope-from="bills@emu-bark.com";
  x-sender="bills@emu-bark.com"; x-conformance=sidf_compatible
Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender
  authenticity information available from domain of
  postmaster@p3plsmtpa06-02.prod.phx3.secureserver.net)
  identity=helo; client-ip=173.201.192.103;
  receiver=mail1-smtp-roc.national.inria.fr;
  envelope-from="bills@emu-bark.com";
  x-sender="postmaster@p3plsmtpa06-02.prod.phx3.secureserver.net";
  x-conformance=sidf_compatible
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiwBAL0huFCtycBnmGdsb2JhbABEwAgWDgEBAQEBCAkNBxQngh4BAQQ5QAY3FhgDAgECAQ88DQYCAQGHegMJBp10l1INiVSLV2mEQQOIXolxgV2HQINfgWqIIA
X-IronPort-AV: E=Sophos;i="4.84,189,1355094000"; 
   d="scan'208";a="183897133"
Received: from p3plsmtpa06-02.prod.phx3.secureserver.net ([173.201.192.103])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 30 Nov 2012 04:06:13 +0100
Received: from [127.0.0.1] ([173.26.186.224])
	by p3plsmtpa06-02.prod.phx3.secureserver.net with 
	id Vf6A1k0034qv3b901f6A80; Thu, 29 Nov 2012 20:06:11 -0700
Message-ID: <50B822A6.7000504@emu-bark.com>
Date: Thu, 29 Nov 2012 22:06:14 -0500
From: William Smith <bills@emu-bark.com>
User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: Caml-list <caml-list@inria.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Caml-list] List.fold_left vs. Hashtbl.fold

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.