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 <[email protected]> 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 <[email protected]> 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 >> > <[email protected]> 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 >> > -- 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
