Re: [Caml-list] Examples where let rec is undesirable

[Gabriel Scherer <gabriel.scherer@gmail.com>]

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 <ivan.chollet@gmail.com> 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 <rich@annexia.org> 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
>> > <dofp.ocaml@gmail.com> 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
>>
>