Re: [Caml-list] Strange behavior of mutualy recursive definitions

[Guillaume Yziquel <guillaume.yziquel@citycable.ch>]

Le Wednesday 27 Apr 2011 à 23:28:52 (+0200), rixed@happyleptic.org a écrit :
> 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.

let rec toto = inc titi and titi = dec toto

This asks to evaluate both toto and titi.

Evaluating toto means feeding an evaluated titi to inc. So you need to
evaluate titi beforehand. Evaluating titi means feeding an evaluated
toto to dec. There's some kind of bootstrap here... that cannot be
solved.

let rec toto x = inc titi x and titi x = dec toto x

This asks to evaluate toto. Well, toto is a function that takes x and
does stuff with it... but this stuff is not done when you evaluate toto.
This stuff is only done when you apply some x value to toto.

This means that you do not need to have titi evaluated in order to be
able to evaluate toto. [rec] keyword: much the same behaviour as 'let
rec f x = f x'; no need to have f evaluated in order to evaluate f.

However, 'let rec f = f' will fail for the exact same reason as before:
To evaluate f, you need to have evaluated f beforehand.

Just focus on the difference between:

	let rec f x = f x
	let rec f = f

That's the only issue you have in your two code samples.

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

No. Not with the address of titi. With a pointer to closure block. and
this closure must be initialised / evaluated beforehand.

In your second case, you do not to have it evaluated beforehand, as it
only makes sense to have it initialised when the function call is made.
The 'rec' keyword allows to tie this knot.

The 'rec' keyword doesn't work in the first case. Just think at what 'let rec
f = f' should compile to...

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

Because in 'let rec f = f', you need to have f evaluated with the code
you give to it: i.e. f. No way.

In 'let rec f x = f x', you're just defining a function that calls
itself repeatitively. It's a tad different.

'let rec f = f' isn't something that calls itself. You're defining it by
hand-waving, essentially saying "be what you are". Quite unhelpful for
the compiler. Why on earth should "be what you are" be interpreted as
"be a function that calls yourself". The former is very problematic. The
latter is very explicit.

-- 
     Guillaume Yziquel