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