From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id AACE97EE51 for ; Mon, 20 May 2013 17:18:16 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of julien.blond@gmail.com) identity=pra; client-ip=209.85.214.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="julien.blond@gmail.com"; x-sender="julien.blond@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of julien.blond@gmail.com designates 209.85.214.174 as permitted sender) identity=mailfrom; client-ip=209.85.214.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="julien.blond@gmail.com"; x-sender="julien.blond@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ob0-f174.google.com) identity=helo; client-ip=209.85.214.174; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="julien.blond@gmail.com"; x-sender="postmaster@mail-ob0-f174.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQCANA9mlHRVdauk2dsb2JhbABAGhaDIq8giWWIOngIFg4BAQEBBwsLCRQEJIIfAQEEAUABGxILAQMBCwYFCwMKDSEiAREBBQEKEgYTEgKHZgEDCQYMM513jD+CfYQdChknAwpYiBABBQyMPoEvgSQEB4NUA5VWgWKBKYp0gz4WKYQ3Og X-IPAS-Result: AjQCANA9mlHRVdauk2dsb2JhbABAGhaDIq8giWWIOngIFg4BAQEBBwsLCRQEJIIfAQEEAUABGxILAQMBCwYFCwMKDSEiAREBBQEKEgYTEgKHZgEDCQYMM513jD+CfYQdChknAwpYiBABBQyMPoEvgSQEB4NUA5VWgWKBKYp0gz4WKYQ3Og X-IronPort-AV: E=Sophos;i="4.87,707,1363129200"; d="scan'208";a="15037240" Received: from mail-ob0-f174.google.com ([209.85.214.174]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 20 May 2013 17:18:15 +0200 Received: by mail-ob0-f174.google.com with SMTP id un3so7193620obb.33 for ; Mon, 20 May 2013 08:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vsNrd435mziGgtGFu+Z8HoroBMngy6wOvscV0EIep24=; b=pM5mP/POWCr+h+xzwBHoQtpW2o0XLPHyW4JG+9m/nnmbTgZT/ybhhtvTZ0xSrANifo zJkigv5LLsnd0owcvma9m0aAc0FIazDaS92arZicyM25n3BnAGljdVFAePiFwqrsG7dm 8GZUR3Lj6DrG2/UTt/i6H/qinRGDLKY/Cm8TM3B610y/YuL66t1TA/NyIdZOQfIZUMwx YTMIo3GQWC0S8BpuAY34DZzKcWyKrdV/ek2VPJQudE0lv6srF7zgWND+5O7iN0c1k5cs t74DsBMqZmyT+93ygNTVq9HzfrZDQDp2i0Gz2vYEJvQuqM8xdT1CoxNMiTZMoTU0mtZp 10dw== MIME-Version: 1.0 X-Received: by 10.182.47.196 with SMTP id f4mr9920610obn.31.1369063094310; Mon, 20 May 2013 08:18:14 -0700 (PDT) Received: by 10.60.174.83 with HTTP; Mon, 20 May 2013 08:18:14 -0700 (PDT) In-Reply-To: References: <1369060290.43256.YahooMailNeo@web120405.mail.ne1.yahoo.com> Date: Mon, 20 May 2013 17:18:14 +0200 Message-ID: From: Julien Blond To: David House Cc: Dario Teixeira , OCaml mailing-list Content-Type: multipart/alternative; boundary=089e0158ad386972e004dd27d78a Subject: Re: [Caml-list] The rec/nonrec debate --089e0158ad386972e004dd27d78a Content-Type: text/plain; charset=ISO-8859-1 I agree that making recursitivy more explicit is... well... more explicit :) But I wonder if, in this case, this is truly relevant. In fact, when I look at OCaml programs, I see many recursive types and very few type shadowing. That is, making types non recursive would add some "rec" or "nonrec" keywords everywhere just to avoid a type alias in a rare case. >From readability point of view, I'm not sure it's a good deal. In the programs I know, the ratio seems to be something like 70/30 for nonrec/rec function while, this time, shadowing is quite often used. Here, explicit "rec" allows us to avoid more "nonrec" elsewhere to continue using shadowing. 2013/5/20 David House > At Jane Street we have a syntax extension that allows one to write > "type nonrec t = ...". > > I too think that non-recursive is the right default. My argument is > mostly as follows: it's nice to have nonrecursive values be the > default, because shadowing is so useful. And it's confusing to have > two different defaults for types and values. > > I also agree that we can't change this for ocaml. > > On 20 May 2013 15:31, Dario Teixeira wrote: > > Hi, > > > > > > As you know, there is in OCaml some asymmetry regarding the rec/nonrec > > defaults for type and value declarations. Types are recursive by default > > and there's no way to "unrecurse" them, whereas values are by default not > > recursive and can be made recursive via the "rec" keyword. > > > > The unrecursiveness of type declarations is cause for some chagrin, as a > > recent ticket on Mantis demonstrates [1]. > > > > Here's something I wonder: if one were to wipe the slate clean, is there > > consensus among the community about the best defaults? I'm leaning > towards > > having nonrec as the default behaviour for *both* types and values, and > > using "rec" as the keyword for recursive types and values. This scheme > > would obviate the need for an actual "nonrec" keyword. > > > > Obviously, such a change would be too intrusive to make to OCaml. > However, > > since people are working on "Next Generation ML" languages like Mezzo > [2], > > I think it would be good to get the community's pulse on this subject. > > (Btw, from the examples posted on Mezzo's homepage, it seems to use the > > same defaults as OCaml). > > > > Your thoughts? > > > > Best regards, > > Dario Teixeira > > > > [1] http://caml.inria.fr/mantis/view.php?id=6016 > > [2] http://gallium.inria.fr/~protzenk/mezzo-lang/ > > > > > > -- > > Caml-list mailing list. Subscription management and archives: > > https://sympa.inria.fr/sympa/arc/caml-list > > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > > Bug reports: http://caml.inria.fr/bin/caml-bugs > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > --089e0158ad386972e004dd27d78a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree that making recursitivy more explicit is... well..= . more explicit :) But I wonder if, in this case, this is truly relevant. I= n fact, when I look at OCaml programs, I see many recursive types and very = few type shadowing. That is, making types non recursive would add some &quo= t;rec" or "nonrec" keywords everywhere just to avoid a type = alias in a rare case. From readability point of view, I'm not sure it&#= 39;s a good deal. In the programs I know, the ratio seems to be something l= ike 70/30 for nonrec/rec function while, this time, shadowing is quite ofte= n used. Here, explicit "rec" allows us to avoid more "nonrec= " elsewhere to continue using shadowing.



201= 3/5/20 David House <dhouse@janestreet.com>
At Jane Street we have a syntax extension that allows one to write
"type nonrec t =3D ...".

I too think that non-recursive is the right default. My argument is
mostly as follows: it's nice to have nonrecursive values be the
default, because shadowing is so useful. And it's confusing to have
two different defaults for types and values.

I also agree that we can't change this for ocaml.

On 20 May 2013 15:31, Dario Teixeira <darioteixeira@yahoo.com> wrote:
> Hi,
>
>
> As you know, there is in OCaml some asymmetry regarding the rec/nonrec=
> defaults for type and value declarations. =A0Types are recursive by de= fault
> and there's no way to "unrecurse" them, whereas values a= re by default not
> recursive and can be made recursive via the "rec" keyword. >
> The unrecursiveness of type declarations is cause for some chagrin, as= a
> recent ticket on Mantis demonstrates [1].
>
> Here's something I wonder: if one were to wipe the slate clean, is= there
> consensus among the community about the best defaults? =A0I'm lean= ing towards
> having nonrec as the default behaviour for *both* types and values, an= d
> using "rec" as the keyword for recursive types and values. = =A0This scheme
> would obviate the need for an actual "nonrec" keyword.
>
> Obviously, such a change would be too intrusive to make to OCaml. =A0H= owever,
> since people are working on "Next Generation ML" languages l= ike Mezzo [2],
> I think it would be good to get the community's pulse on this subj= ect.
> (Btw, from the examples posted on Mezzo's homepage, it seems to us= e the
> same defaults as OCaml).
>
> Your thoughts?
>
> Best regards,
> Dario Teixeira
>
> [1] http://caml.inria.fr/mantis/view.php?id=3D6016
> [2] http://gallium.inria.fr/~protzenk/mezzo-lang/
>
>
> --
> Caml-list mailing list. =A0Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

--
Caml-list mailing list. =A0Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

--089e0158ad386972e004dd27d78a--