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 q0388AVv012392 for ; Tue, 3 Jan 2012 09:08:10 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEHAJ22Ak9KfVI0kGdsb2JhbABEggWaKZAmCCIBAQEBCQkNBxQEIYFyAQEBAwESAiwBGxILAQMBCwYFCw0NISEBAREBBQEKEgYTEgkHh1gImDEKi2WCa4QYP4hxAgULg3KIEgSVAopvgw49g3s X-IronPort-AV: E=Sophos;i="4.71,448,1320620400"; d="scan'208";a="137607298" Received: from mail-ww0-f52.google.com ([74.125.82.52]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-MD5; 03 Jan 2012 09:08:05 +0100 Received: by wgbdr12 with SMTP id dr12so31771750wgb.9 for ; Tue, 03 Jan 2012 00:08:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=dGAzIo3Qfnx2Jluiz5iIIR2kXrNnWQYEljUjgbJ+BvY=; b=kfLejAatVa/TKIvbcX5QlAFRW/anr1L9QOtZ59zPwSTk4oE3ObSPsYzYaCJQpPRt50 kOxmeCq1++gmo2coT2uJCq2T7tWpcMPlCUCysUl4Kukmp07RQg/hKnypMWvIY9XGIBBO sQeO4sdHuls1Du48Y+lX8q5drTdw9wMEmSZEY= Received: by 10.227.208.13 with SMTP id ga13mr62866384wbb.4.1325578084380; Tue, 03 Jan 2012 00:08:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.227.198.147 with HTTP; Tue, 3 Jan 2012 00:07:43 -0800 (PST) In-Reply-To: <4F02967A.7060303@ens-lyon.org> References: <4F02967A.7060303@ens-lyon.org> From: Gabriel Scherer Date: Tue, 3 Jan 2012 09:07:43 +0100 Message-ID: To: Martin Jambon Cc: Lukasz Stafiniak , Diego Olivier Fernandez Pons , caml-list Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q0388AVv012392 Subject: Re: [Caml-list] Examples where let rec is undesirable > What I am wondering is why type definitions are recursive by default. It > is mostly troubling for beginners. Indeed, it is a defect of the language not to have non-recursive type definitions. My usual reference on this topic is Yaron's complaint: https://ocaml.janestreet.com/?q=node/25 The problem is not so much that they are "recursive by default" (I believe this would be justified by the relative frequencies of recursive type definitions and type-level name recycling) but that they *must* be recursive. It would be better to have some kind of "type-nonrec" construct for non-recursive type declarations. This is however a case were it is difficult to fix the issue in a fully convenient way: you don't want to add a new keyword, you certainly don't want to change the behavior of existing "type" declarations, and all solutions remaining are likely to be convoluted and feel like a ad-hoc patch. Given there is the reasonable (if ugly) workaround of breaking the cycle through an auxiliary type renaming, there are few incentives to change the state of the art. I believe this is something you could and should easily fix when designing a new language (when introducing *any* binding construct, think about both a recursive (when it makes sense) and a non-recursive version), but that may have to stay with us for OCaml. On Tue, Jan 3, 2012 at 6:47 AM, Martin Jambon wrote: > On 01/02/2012 04:05 PM, Lukasz Stafiniak wrote: >> On Mon, Jan 2, 2012 at 11:37 PM, Diego Olivier Fernandez Pons >> 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 > > -- > 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 >