From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: * X-Spam-Status: No, score=1.4 required=5.0 tests=AWL,MAILTO_TO_SPAM_ADDR, SPF_NEUTRAL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id B1B6FBC6B for ; Sat, 4 Aug 2007 15:26:34 +0200 (CEST) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.227]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l74DQYtx028121 for ; Sat, 4 Aug 2007 15:26:34 +0200 Received: by hu-out-0506.google.com with SMTP id 16so768041hue for ; Sat, 04 Aug 2007 06:26:33 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:received:date:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:from; b=Guxhg5flQpDwzHh0ZbBsAf1C4KrltIpnGHy2uc122SH0qURTyb3nIrtM7Ty4EVZ0ea0m/dT06F44gt/kAj6PDwA52gZhhtB82l/xWOFkqbUoNIaIomzDQ/Qc2t5n1bwOCyblP3w9q+aK9/XGF/vKSJslLlhlyHehoxex0Gsxk5k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:to:cc:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:from; b=edvRVkyIaKILFa7zOBAGFM7dixfaRDE3gQOSM8S50R9NnNUdfuXLH7oc+UaoZcqoJ7meNvQpERj5wXnWp8ZlAYqv6LPZEjpc7s9+luzQdPC6wrXVQeE9NWRMYbUvR0f9+hBvC8IsXQcxP8Ogs+Go9HmToWWvKJSVTLCOAURsYlc= Received: by 10.86.89.4 with SMTP id m4mr2995593fgb.1186233993630; Sat, 04 Aug 2007 06:26:33 -0700 (PDT) Received: from localhost ( [82.122.232.94]) by mx.google.com with ESMTPS id f19sm8462001fka.2007.08.04.06.26.30 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Aug 2007 06:26:31 -0700 (PDT) Received: by localhost (sSMTP sendmail emulation); Sat, 04 Aug 2007 15:26:22 +0200 Date: Sat, 4 Aug 2007 15:26:22 +0200 To: Oliver Bandel Cc: caml-list@inria.fr Subject: Re: [Caml-list] Warning on not-tail recursive functions Message-ID: <20070804132621.GA5804@jiyu.gnu> Mail-Followup-To: Julien Moutinho , Oliver Bandel , caml-list@inria.fr References: <46B45BE3.9040403@menta.net> <1186230861.46b4724d1561e@webmail.in-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1186230861.46b4724d1561e@webmail.in-berlin.de> User-Agent: Mutt/1.5.16 (2007-06-11) From: Julien Moutinho X-j-chkmail-Score: MSGID : 46B47E8A.000 on discorde : j-chkmail score : X : 0/20 1 0.000 -> 1 X-Miltered: at discorde with ID 46B47E8A.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; recursive:01 0200,:01 bandel:01 ocamlopt:01 recursive:01 tail-call:01 tailcall:01 tailcall:01 2007,:98 wrote:01 wrote:01 oliver:01 rec:01 caml-list:01 functions:01 On Sat, Aug 04, 2007 at 02:34:21PM +0200, Oliver Bandel wrote: > Zitat von Brian Hurt : > > On Sat, 4 Aug 2007, tmp123@menta.net wrote: > > > Please, knows someone if "ocamlopt" can print a warning message when a > > > recursive function is not tail recursive, and code with the "jmp" > > > optimization has not been generated?. > > > > The problem is that I often write recursive functions which are not tail > > recursive, and that's OK. Ibid. > > The rules for what is or is not tail recursive are pretty simple. Boiled > > down, they are: > > 1) The tail call must not be within a try expression > > 2) You can not do anything except return, uninspected and unmodified, the > > returned value from the call. I agree Mr.Hurt. > Does ignore REALLY ignore the values (does not generate them), so that > this call is like a true tail-call, No, [ignore] is not a macro, so it always triggers the calculation of its argument. Think about ignore as if it would be [let ignore _ = ()] Note however that it is not truly the case, and that [ignore == ignore] is false, since [ignore] is actually defined as an external value [external ignore : 'a -> unit = "%ignore"] > or will the maybe_tailcall > generate and give back results to the ignore-call and then > ignore throws away the stuff (then it would be NO tailcall). Yes, AFAICS with the -S option, neither [ignore] nor [let _ = your_rec_fun in ()] are segregated from the other functions to produce jumps. And I perfectly understand that the Inrians work on more important optimizations than those.