From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q035dtR5008838
	for <caml-list@sympa-roc.inria.fr>; Tue, 3 Jan 2012 06:39:55 +0100
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap0DAFyTAk9CbwQdkWdsb2JhbABDggWDCqdOIgEBAQEJCwsHFAQhgXIBAQUjHTgBAQ8LDgoCAgUWCwICCQMCAQIBDzYGDQEFAgEBqltqkGwHgS+JSoEWiDuSGoUgh2Y
X-IronPort-AV: E=Sophos;i="4.71,447,1320620400"; 
   d="scan'208";a="137595349"
Received: from out5.smtp.messagingengine.com ([66.111.4.29])
  by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 03 Jan 2012 06:39:50 +0100
Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42])
	by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id E76A920DCB
	for <caml-list@inria.fr>; Tue,  3 Jan 2012 00:39:48 -0500 (EST)
Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161])
  by compute2.internal (MEProxy); Tue, 03 Jan 2012 00:39:48 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=
	messagingengine.com; h=message-id:date:from:mime-version:to:cc
	:subject:references:in-reply-to:content-type
	:content-transfer-encoding; s=smtpout; bh=hZXDUA3b/ZZUXIOM7/Bbu9
	iMjpc=; b=DZewG67toKF45oo6zt06U2H6nz1mnyO9we2nHiJZ6jYmtdWXB2Ft4j
	xccT0cWIKblCqYf1738YmTykJJjzLC/HEt9s1hclVtmNGFURM7bkghSoyTiaNtfD
	Wssov8d6IuDBxjUskE7Jo8onT+oT3BtaBgHQ+73iX3v30Zucx/jE0=
X-Sasl-enc: SfZlP0LOZyRfOHiw3CAAnQftIqgU1t3Ixgrf383umCzo 1325569188
Received: from [192.168.2.4] (c-98-248-39-171.hsd1.ca.comcast.net [98.248.39.171])
	by mail.messagingengine.com (Postfix) with ESMTPSA id 61AF848249C;
	Tue,  3 Jan 2012 00:39:48 -0500 (EST)
Message-ID: <4F02967A.7060303@ens-lyon.org>
Date: Mon, 02 Jan 2012 21:47:38 -0800
From: Martin Jambon <martin.jambon@ens-lyon.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.9) Gecko/20101023 Lightning/1.0b3pre Thunderbird/3.1.3
MIME-Version: 1.0
To: Lukasz Stafiniak <lukstafi@gmail.com>
CC: Diego Olivier Fernandez Pons <dofp.ocaml@gmail.com>,
        caml-list <caml-list@inria.fr>
References: <CAHqiZ-LhsBa4Xn51dCDAeOpTVMzF8kJCestAGydh5abMHsOidQ@mail.gmail.com> <CAJMfKEU8y0MiRn_1N1qjWQdi7bTzHgVC4xfkLkDrktJUecbngg@mail.gmail.com>
In-Reply-To: <CAJMfKEU8y0MiRn_1N1qjWQdi7bTzHgVC4xfkLkDrktJUecbngg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Caml-list] Examples where let rec is undesirable

On 01/02/2012 04:05 PM, 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?

What I am wondering is why type definitions are recursive by default. It
is mostly troubling for beginners.

The following is an occasional inconvenience of having only recursive
type definitions:

module A =
struct
  type t = ...
  let compare = ...

  module B =
  struct
    type t = t (* uh oh *)
    let compare = compare
  end
end


Martin