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

[ivan chollet <ivan.chollet@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1860 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 2674 bytes --]