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 p3RKl6jN030336 for ; Wed, 27 Apr 2011 22:47:06 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIEAIt/uE3UGyoFkWdsb2JhbACYQ40uFAEBAQEJCwsHFAMixFWFdgSScA+KAA X-IronPort-AV: E=Sophos;i="4.64,276,1301868000"; d="scan'208";a="106937182" Received: from smtp5-g21.free.fr ([212.27.42.5]) by mail1-smtp-roc.national.inria.fr with ESMTP; 27 Apr 2011 22:47:01 +0200 Received: from yeeloong (unknown [82.67.194.89]) by smtp5-g21.free.fr (Postfix) with SMTP id EED42D48035 for ; Wed, 27 Apr 2011 22:46:53 +0200 (CEST) Received: by yeeloong (sSMTP sendmail emulation); Wed, 27 Apr 2011 22:46:29 +0200 Date: Wed, 27 Apr 2011 22:46:29 +0200 From: rixed@happyleptic.org To: caml-list@inria.fr Message-ID: <20110427204629.GA8872@yeeloong.happyleptic.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [Caml-list] Strange behavior of mutualy recursive definitions 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?