From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id p3RKtlYw030700 for ; Wed, 27 Apr 2011 22:55:47 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcCACiCuE1V2gB5mWdsb2JhbACYQ41CAQEBAQEICwsHFCXETQ6FaASSf4oA X-IronPort-AV: E=Sophos;i="4.64,276,1301868000"; d="scan'208";a="98201420" Received: from emailfrontal2.citycable.ch ([85.218.0.121]) by mail2-smtp-roc.national.inria.fr with SMTP; 27 Apr 2011 22:55:42 +0200 X-Alinto-smtpauth-localdomain: Yes Received: from seldon (unknown [85.218.93.111]) (Authenticated sender: guillaume.yziquel@citycable.ch) by emailfrontal2.citycable.ch (Postfix) with ESMTPA id 6569CF08005; Wed, 27 Apr 2011 22:55:39 +0200 (CEST) Received: from yziquel by seldon with local (Exim 4.72) (envelope-from ) id 1QFBkW-0007BL-JI; Wed, 27 Apr 2011 22:54:16 +0200 Date: Wed, 27 Apr 2011 22:54:16 +0200 From: Guillaume Yziquel To: rixed@happyleptic.org Cc: caml-list@inria.fr Message-ID: <20110427205416.GL4023@localhost> References: <20110427204629.GA8872@yeeloong.happyleptic.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20110427204629.GA8872@yeeloong.happyleptic.org> User-Agent: Mutt/1.5.20 (2009-06-14) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id p3RKtlYw030700 Subject: Re: [Caml-list] Strange behavior of mutualy recursive definitions Le Wednesday 27 Apr 2011 à 22:46:29 (+0200), rixed@happyleptic.org a écrit : > I met this strangeness today and would like to know is it a FAQ? Is it > intentional? Is it fixable? > > # let inc f x = (f x)+1 and dec f x = (f x)-1;; > val inc : ('a -> int) -> 'a -> int = > val dec : ('a -> int) -> 'a -> int = > # let rec toto = inc titi and titi = dec toto;; > Error: This kind of expression is not allowed as right-hand side of `let rec' > > Now after reading http://caml.inria.fr/pub/docs/manual-ocaml/manual021.html#s:letrecvalues , > this is unclear why toto and titi definitions are not 'statistically constructive': > It seams that one could trivially add a "fun f -> ... f" around the > function bodies in order to comply with the rules. And actually, this > even simpler (but to my knowledge equivalent) definition works : > > # let rec toto x = inc titi x and titi x = dec toto x;; > val toto : 'a -> int = > val titi : 'a -> int = > > So why was the first version rejected? Because to evaluate toto, you need to have titi evaluated beforehand (wouldn't be the case if you had 'let rec toto = titi inc' instead of 'inc titi', typically). And to evaluate titi, you need to have evaluated beforehand the value toto. The second version only defines toto as a function that calls titi. No need to have titi evaluated to be able to evalue toto. You only need to know where it is declared. That's the main difference. -- Guillaume Yziquel