From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=AWL,DNS_FROM_SECURITYSAGE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id A5BDBBBAF for ; Sun, 26 Oct 2008 01:16:00 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMAAMpFA0lCbwQbi2dsb2JhbACTewEBAQoLCgcPBqxGg08 X-IronPort-AV: E=Sophos;i="4.33,486,1220220000"; d="scan'208";a="19194431" Received: from out3.smtp.messagingengine.com ([66.111.4.27]) by mail1-smtp-roc.national.inria.fr with ESMTP; 26 Oct 2008 01:16:00 +0200 Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 60D51183034; Sat, 25 Oct 2008 19:15:59 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Sat, 25 Oct 2008 19:15:59 -0400 X-Sasl-enc: Msv70tnD9Z05OzcyG79fWkAieoOMT2UaiRO5OujUsVwt 1224976558 Received: from [192.168.1.10] (ALyon-157-1-83-127.w90-37.abo.wanadoo.fr [90.37.194.127]) by mail.messagingengine.com (Postfix) with ESMTPSA id 9CEFC12B2D; Sat, 25 Oct 2008 19:15:58 -0400 (EDT) Message-ID: <4903A6F0.5000303@ens-lyon.org> Date: Sun, 26 Oct 2008 01:08:32 +0200 From: Martin Jambon User-Agent: Thunderbird 2.0.0.17 (X11/20081008) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Cc: caml-list caml-list Subject: Indentation (was Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?) References: <200810200919.41561.ober.14@osu.edu> <9d3ec8300810211231j40dbbef2ifdd6c2f6b84a2048@mail.gmail.com> <20081021202649.GA11380@philou.ch> <200810220842.17128.ober.14@osu.edu> <49002C0E.5050107@inescporto.pt> <49003554.9050109@lri.fr> <9722eaea0810230313u25b2c874xc94574786e513162@mail.gmail.com> <4900596C.80406@inescporto.pt> <20081023141335.GA521@snarc.org> <49008D7D.4060908@lri.fr> <490096B8.3020602@ramenlabs.com> <4902F183.5060504@doomeer.com> <4903145E.5050904@ens-lyon.org> <483673C5-ED3C-4877-AC85-D89E1CA6A1D2@erratique.ch> In-Reply-To: <483673C5-ED3C-4877-AC85-D89E1CA6A1D2@erratique.ch> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam: no; 0.00; ens-lyon:01 bunzli:01 blabla:01 model:01 closures:01 wrote:01 clearer:01 caml-list:01 functions:01 functions:01 imperative:01 jambon:01 jambon:01 closure:01 define:02 Daniel Bünzli wrote: > > Le 25 oct. 08 à 14:43, Martin Jambon a écrit : > >> Now I generally tend to use this: >> >> let x = >> List.map ( >> fun z -> >> very_blabla >> ... >> ) my_list >> in > > I think the best solution is to name your anonymous function, as the > guidelines suggest [1]. It says: "Justification: Much clearer, in particular if the name given to the function is meaningful." I think that's true for typical functional code which follows some clear logic or model. In many cases it's not possible to give a meaningful name to such a function and defining it out of the current block can make things needlessly hard to follow. I can think of 4 cases: 1. anonymous function that fits on one line 2. anonymous function that doesn't fit on one line (my original example) 3. named function defined locally using let-in 4. named function defined globally using let I don't use (3) very much since: * it still causes the outermost function definition to be very long and hard to follow like (2), * and it's okay to define a function globally (4) because there is no serious risk of global namespace pollution, thanks to the module system. I think (3) is most useful for defining named functions that depend on a lot of locally-defined values. This creates a closure, which is often acceptable performance-wise, instead of having to make each parameter of the function explicit. In performance-critical code or maybe imperative code in general, it feels good to control when closures are created. In such cases, avoiding local functions helps. Martin -- http://mjambon.com/