From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q05NGLmY007383 for ; Fri, 6 Jan 2012 00:16:21 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMDAFEuBk/RVdK2kWdsb2JhbABCggWpfXcIIgEBAQEJCQ0HEieBcgEBAQMBEgIsARsdAQMBCwYFBAcNLiIBEQEFARwGEyKHWJlFCotngm+EVT+IcQIFC4wGBJUGjX49g3o X-IronPort-AV: E=Sophos;i="4.71,464,1320620400"; d="scan'208";a="125766913" Received: from mail-iy0-f182.google.com ([209.85.210.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 06 Jan 2012 00:16:15 +0100 Received: by iadj38 with SMTP id j38so2481923iad.27 for ; Thu, 05 Jan 2012 15:16:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G2nky3cwUz1ngPoXAXx3F67RSQQzntoeP+BCkNOdS3Q=; b=XWoMgl937exRxkSBXiRt57QxHSIYYUjtXK9i0uA/8/gktBMtwvnVrRlpfeYJmDmheq XW/EnSv4Ua4t1zGN41kfGY3LmQgv78uYFdDz8FAvI3QfCF0E6WXcw6WM5b9Lp8TLqXCF pPOV0gIxkoCfPL6+dPhgxnaHB21asAC/VybHU= MIME-Version: 1.0 Received: by 10.50.188.166 with SMTP id gb6mr4905726igc.18.1325805374327; Thu, 05 Jan 2012 15:16:14 -0800 (PST) Received: by 10.42.163.3 with HTTP; Thu, 5 Jan 2012 15:16:14 -0800 (PST) In-Reply-To: <20120105213636.GA30972@annexia.org> References: <20120105200442.GA17669@annexia.org> <20120105213636.GA30972@annexia.org> Date: Thu, 5 Jan 2012 23:16:14 +0000 Message-ID: From: ivan chollet To: "Richard W.M. Jones" Cc: Lukasz Stafiniak , Diego Olivier Fernandez Pons , caml-list Content-Type: multipart/alternative; boundary=14dae934068b60cd6b04b5d01e7e Subject: Re: [Caml-list] Examples where let rec is undesirable --14dae934068b60cd6b04b5d01e7e Content-Type: text/plain; charset=ISO-8859-1 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 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 > --14dae934068b60cd6b04b5d01e7e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry Richard I should have elaborated a bit more.
I guess there are a c= ouple of examples in the literature, but one of them comes to my mind, cons= ider the following code snippet:

let fd =3D Unix.open "myfile1&= quot; ... in
let fd =3D 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 shadow= ing since then.
As a rule of thumb, I think it's better to give different conceptual ob= jects different variable names, which also improves self-documentation. Wit= hin nested scopes, all objects declared with a let-binding are usually dist= inct conceptually.
Across independent scopes, of course code fragments are independent and var= iable naming schemes are independent, however within nested scopes, my opin= ion is that variable shadowing is bad practice, for the reason exemplified = above.
More generally, one of the reason why developers like languages like Caml i= s that features like strong typing, ADT, pattern matching prevents them to = be bitten by their own code, while still preserving a high level of express= iveness. Because there is no free lunch, this also increase the cognitive b= urden 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<= br> > expressive, but opens the door to bugs that can be harder to track by<= br> > 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? =A0Surely if it's bad at all, every
local variable in the whole program should have a unique name?

Rich.

--
Richard Jones
Red Hat

--14dae934068b60cd6b04b5d01e7e--