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 p3RLTOeG032433
	for <caml-list@sympa-roc.inria.fr>; Wed, 27 Apr 2011 23:29:25 +0200
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhIEAFGKuE3UGyoFkWdsb2JhbACYSY0uFAEBAQEJCwsHFAMiiHC8CYV2BJJwD4oA
X-IronPort-AV: E=Sophos;i="4.64,276,1301868000"; 
   d="scan'208";a="98202638"
Received: from smtp5-g21.free.fr ([212.27.42.5])
  by mail2-smtp-roc.national.inria.fr with ESMTP; 27 Apr 2011 23:29:24 +0200
Received: from yeeloong (unknown [82.67.194.89])
	by smtp5-g21.free.fr (Postfix) with SMTP id 24816D48201
	for <caml-list@inria.fr>; Wed, 27 Apr 2011 23:29:16 +0200 (CEST)
Received: by yeeloong (sSMTP sendmail emulation); Wed, 27 Apr 2011 23:28:52 +0200
Date: Wed, 27 Apr 2011 23:28:52 +0200
From: rixed@happyleptic.org
To: caml-list@inria.fr
Message-ID: <20110427212852.GC8872@yeeloong.happyleptic.org>
References: <20110427204629.GA8872@yeeloong.happyleptic.org>
 <20110427205416.GL4023@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110427205416.GL4023@localhost>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [Caml-list] Strange behavior of mutualy recursive definitions

Thank you for the explanation but I fear they are not enough for me to
understand.  Specifically, I do not understand why to compile "let rec
toto = inc titi and titi = dec toto" this is not enough to know the
address of titi and toto functions. I don't see what's the difference
from let rec toto = titi inc ..." in this regard.

> 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.

But in the first version, toto is a function that calls inc with, as
first parameter, the address of titi. I don't see why it's more complex.

And suppose I would understand this, I'd still have to figure out why
merely adding the mute variable x suddenly turns the definitions valid.