From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr 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 41AF37EE51 for ; Mon, 20 May 2013 17:17:57 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of edwin+ml-ocaml@etorok.net) identity=pra; client-ip=176.9.138.55; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of edwin+ml-ocaml@etorok.net designates 176.9.138.55 as permitted sender) identity=mailfrom; client-ip=176.9.138.55; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="edwin+ml-ocaml@etorok.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of postmaster@mail.etorok.net designates 176.9.138.55 as permitted sender) identity=helo; client-ip=176.9.138.55; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="edwin+ml-ocaml@etorok.net"; x-sender="postmaster@mail.etorok.net"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFANA9mlGwCYo3/2dsb2JhbABagmchwW+BABZ0gh8BAQVAAQE2Ag8LGAkWDwkDAgECAUUTCAIQh3oDqTCEPgEFjVYGjygWgz6JHI4fkUCDEg X-IPAS-Result: AgMFANA9mlGwCYo3/2dsb2JhbABagmchwW+BABZ0gh8BAQVAAQE2Ag8LGAkWDwkDAgECAUUTCAIQh3oDqTCEPgEFjVYGjygWgz6JHI4fkUCDEg X-IronPort-AV: E=Sophos;i="4.87,707,1363129200"; d="scan'208";a="15037218" Received: from mail.etorok.net ([176.9.138.55]) by mail3-smtp-sop.national.inria.fr with ESMTP; 20 May 2013 17:17:56 +0200 Received: from [IPv6:2a02:2f09:40b0:90:5c88:2cf5:59e4:9a4f] (unknown [IPv6:2a02:2f09:40b0:90:5c88:2cf5:59e4:9a4f]) by mail.etorok.net (Postfix) with ESMTPSA id 0D1D946AF for ; Mon, 20 May 2013 17:17:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=etorok.net; s=MAILOUT; t=1369063075; bh=o6Xe7OSPC3X+pP4munq+RBVGdoMcTazMpfJw09DOHqI=; h=Date:From:To:Subject:References:In-Reply-To:From; b=pHmJKLcjW3YpO2BJgCIcWcyxOhauVeC9gHTD/Fxdgi6KaAz2s3h8PL3itddbJOoUQ bl9AlAnEDQWtfZI4QKHDFQM1mP6MHURo+9TslhIWssaOen2HnLo1gaVquU0qQCzydZ Ic7unN6E9OUPYxcwbEfrztdCsP8P5ZeuDxRbHwwg= Message-ID: <519A3EA2.9080804@etorok.net> Date: Mon, 20 May 2013 18:17:54 +0300 From: =?ISO-8859-1?Q?T=F6r=F6k_Edwin?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5 MIME-Version: 1.0 To: caml-list@inria.fr References: <1369060290.43256.YahooMailNeo@web120405.mail.ne1.yahoo.com> In-Reply-To: <1369060290.43256.YahooMailNeo@web120405.mail.ne1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: Re: [Caml-list] The rec/nonrec debate On 05/20/2013 05:31 PM, Dario Teixeira wrote: > 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? Functions should definitely be non-recursive by default (like in OCaml), to at least explicitly make you think about the termination/stack usage consequences. For types I'd prefer non-recursive by default, but only for consistency reasons. For 'rec' on functions it'd be nice if there was a way to require tail-recursivity, and have the compiler reject the code if its not actually tail-recursive or calls non-tail-recursive functions. But what should be the default? If we apply the same reasoning as for 'rec' (require explicity action for possibly unsafe structure), then tail-recursive-required should be default, and you'd need a 'nontail' keyword. That may be somewhat unpractical though, as most tree-handling code would have to be full of 'nontail'. Perhaps a more practical approach would be to have this only at the documentation level, i.e. Mezzo's equivalent of ocamldoc would show a red 'non tail recursive' marker in the function's doc to alert users to the non-tail-recursive functions (and a green tail-recursive marker for others). In fact this might be a nice improvement to ocamldoc too. Best regards, --Edwin