Mailing list for all users of the OCaml language and system.
 help / color / mirror / Atom feed
From: ivan chollet <ivan.chollet@gmail.com>
To: "Richard W.M. Jones" <rich@annexia.org>
Cc: Lukasz Stafiniak <lukstafi@gmail.com>,
	Diego Olivier Fernandez Pons <dofp.ocaml@gmail.com>,
	caml-list <caml-list@inria.fr>
Subject: Re: [Caml-list] Examples where let rec is undesirable
Date: Thu, 5 Jan 2012 23:16:14 +0000	[thread overview]
Message-ID: <CACm_MF-hxbJEo=g4wNgN-YmHE+EeQzoUiDCMqEszOOgoOJfsdw@mail.gmail.com> (raw)
In-Reply-To: <20120105213636.GA30972@annexia.org>

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

Sorry Richard I should have elaborated a bit more.
I guess there are a couple of examples in the literature, but one of them
comes to my mind, consider the following code snippet:

let fd = Unix.open "myfile1" ... in
let fd = Unix.open "myfile2" ... in
... (some code)
Unix.close fd

This causes a file descriptor leak that is hard to detect statically in
general. This happened to me, i tend to avoid variable shadowing since then.
As a rule of thumb, I think it's better to give different conceptual
objects different variable names, which also improves self-documentation.
Within nested scopes, all objects declared with a let-binding are usually
distinct conceptually.
Across independent scopes, of course code fragments are independent and
variable naming schemes are independent, however within nested scopes, my
opinion is that variable shadowing is bad practice, for the reason
exemplified above.
More generally, one of the reason why developers like languages like Caml
is that features like strong typing, ADT, pattern matching prevents them to
be bitten by their own code, while still preserving a high level of
expressiveness. Because there is no free lunch, this also increase the
cognitive burden on the developer at write-time, and is the price to pay to
write code with less bugs.

Hope this clarifies my point of view a little.


On Thu, Jan 5, 2012 at 9:36 PM, Richard W.M. Jones <rich@annexia.org> wrote:

> On Thu, Jan 05, 2012 at 08:27:25PM +0000, 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.
>
> You'll have to explain a bit more why this is.
>
> Also, why is variable shadowing bad within a function (in C), but just
> fine across different functions?  Surely if it's bad at all, every
> local variable in the whole program should have a unique name?
>
> Rich.
>
> --
> Richard Jones
> Red Hat
>

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

  reply	other threads:[~2012-01-05 23:16 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-02 22:37 Diego Olivier Fernandez Pons
2012-01-02 22:49 ` Alexandre Pilkiewicz
2012-01-03  0:05 ` Lukasz Stafiniak
2012-01-03  5:47   ` Martin Jambon
2012-01-03  8:07     ` Gabriel Scherer
2012-01-05 20:04   ` Richard W.M. Jones
2012-01-05 20:27     ` ivan chollet
2012-01-05 20:46       ` Gabriel Scherer
2012-01-05 21:39         ` Richard W.M. Jones
2012-01-06  2:39           ` Cedric Cellier
2012-01-06 15:22         ` Damien Doligez
2012-01-05 21:36       ` Richard W.M. Jones
2012-01-05 23:16         ` ivan chollet [this message]
2012-01-06  8:34           ` David Allsopp
2012-01-06 10:34           ` Daniel Bünzli
2012-01-03 13:05 ` Yaron Minsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACm_MF-hxbJEo=g4wNgN-YmHE+EeQzoUiDCMqEszOOgoOJfsdw@mail.gmail.com' \
    --to=ivan.chollet@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=dofp.ocaml@gmail.com \
    --cc=lukstafi@gmail.com \
    --cc=rich@annexia.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox