From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q05Kl0ZZ004318 for ; Thu, 5 Jan 2012 21:47:00 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtwBANsLBk/RVdS2kGdsb2JhbABCggWaPZA0CCIBAQEBCQkNBxQEIYFyAQEBBBICLAEbEAIIAwEDDAYFCw0NISEBAREBBQEKEgYTEhCHYJk1Cotngm+EWD+IcQIFC4NyiBQElQaKcIMOPYN7 X-IronPort-AV: E=Sophos;i="4.71,464,1320620400"; d="scan'208";a="138041447" Received: from mail-wi0-f182.google.com ([209.85.212.182]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 05 Jan 2012 21:46:54 +0100 Received: by wibhr1 with SMTP id hr1so1254625wib.27 for ; Thu, 05 Jan 2012 12:46:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=dLzoA9G2XJnEv++1d7wEOAX+LbrB4hi/1KidmTplIHU=; b=iZWg/7x+c7OdVI/0YF58qJxRPDMXx+IhdSDjrnc8UXUMztz6m3ZESp6FA9IxnJlCr9 kHCVtIQOyObRrr10e4+wbDKxVZuJ3KupuCVgP+JVTMcbstIuTtWAcm/qvZP5RrcnoG8n m3v5mSDPoi5wB+9MBXqWbNnDuetslDGUygpJk= Received: by 10.180.83.104 with SMTP id p8mr2885242wiy.4.1325796413637; Thu, 05 Jan 2012 12:46:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.198.147 with HTTP; Thu, 5 Jan 2012 12:46:32 -0800 (PST) In-Reply-To: References: <20120105200442.GA17669@annexia.org> From: Gabriel Scherer Date: Thu, 5 Jan 2012 21:46:32 +0100 Message-ID: To: ivan chollet Cc: "Richard W.M. Jones" , Lukasz Stafiniak , Diego Olivier Fernandez Pons , caml-list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q05Kl0ZZ004318 Subject: Re: [Caml-list] Examples where let rec is undesirable My argument is the following: when you make a *local* edition to a piece of code, shadowing allow you to pick variable name without having to know about what's already bound in context. If you can't shadow, you have to keep in mind what is in the context, which increases the cognitive burden (during code edition) and also the maintenance cost in some situations, such as "moving this (self-contained) piece of code to this place (possibly with a different context)". I have also found language that disallow shadowing to be a pain in practice, and you can find concrete examples of this in Erlang and, to a lesser extent, Haskell. In Erlang, you will often find patterns that look (once translated to ML) like this let x1 = foo x in let x2 = bar x1 in let x3 = blah x2 in foobar x3 (In Haskell those don't appear as is because you will use function composition or a State monad; but you can still find "x1", or "x prime", as a common and awkward idiom) This style is painful to maintain: if you suddently wish to add an intermediate step, you have important non-local change to make, which increase the opportunity for bugs, or at least source inconsistencies. The flipside of my meta-argument above (disallowing shadowing increase context-dependency a lot) is that some people argue that the problem is not with forbidding shadowing, but with having a non-trivial outside context. Bindings, they argue, should not be nested, and you should never have more than two, three layers of scope in your code. Making non-trivial environments harder is nearly an explicit goal of their language design choice, and they are therefore more than happy to forbid shadowing. For example, that the position of the Coffeescript designer (a syntactic sugar layer of Javascript which is getting popular for using indentation over braces, but has made the imho. awful choice of making it nearly impossible to define a local variable). It is a rational choice, but I still disagree strongly; I find all arguments of the shape "you will never have more than N of these things, or you're guilty of doing something wrong" dubious. On Thu, Jan 5, 2012 at 9:27 PM, ivan chollet wrote: > Allowing variable shadowing is aesthetically more satisfying and more > expressive, but opens the door to bugs that can be harder to track by static > analysis. > I would be interested to hear the pro-arguments for variable shadowing, > besides the slight gain in expressiveness. > > > > On Thu, Jan 5, 2012 at 8:04 PM, Richard W.M. Jones wrote: >> >> On Tue, Jan 03, 2012 at 01:05:39AM +0100, Lukasz Stafiniak wrote: >> > On Mon, Jan 2, 2012 at 11:37 PM, Diego Olivier Fernandez Pons >> > wrote: >> > >     List, >> > > >> > > I was wondering if there was any reason not to make "let rec" the >> > > default / >> > > sole option, meaning cases where you clearly don't want a "let rec" >> > > instead >> > > of "let" (only in functions, not cyclic data). >> > > >> > >          Diego Olivier >> > >> > The default "no-rec" allows for name recycling -- using the same name >> > for an incrementally transformed value, i.e. to bind the intermediate >> > results. Name recycling minimizes the cognitive burden: there are less >> > names to remember in a scope, and differences in names are justified >> > by differences in purpose of the values. Are there reasons to consider >> > name recycling a bad style? >> >> I had an argument about this with a noted open source developer >> recently.  He was saying that C's approach -- not permitting variable >> names to be reused within a single function -- was somehow >> advantageous.  From my point of view, having used both languages >> extensively, OCaml's way is *far* better. >> >> So yes, 'let' and 'let rec', long may they be different. >> >> Rich. >> >> -- >> Richard Jones >> Red Hat >> >> -- >> Caml-list mailing list.  Subscription management and archives: >> https://sympa-roc.inria.fr/wws/info/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs >> >