Re: [Caml-list] Mutual recursion propagates individual recursion. Why?

[Ben Millwood <bmillwood@janestreet.com>]

[-- Attachment #1: Type: text/plain, Size: 3917 bytes --]

As an illustrative example of the use of non-recursive and: [let x = y and
y = x in ...] swaps the values of x and y.

On 2 March 2015 at 07:25, Gabriel Scherer <gabriel.scherer@gmail.com> wrote:

>   let x1 = e1 and x2 = e2 and ... and xn = en in body
>
> Has the effect that the x1,x2,..,xn are bound "simultaneously" in body,
> and not before. Unlike what "let x1 = e1 in let x2 = e2 in ..." does, x1 is
> not visible in e2, etc. This is rarely useful when programming, but
> extremely useful when meta-programming, as it allows you to evaluate
> several different pieces of code in the same scope independently, without
> risk of variable shadowing.
>
> For the record I don't find your feature suggestion particularly tempting.
> Mutual recursion is more expressive than single-recursion, and I'm not sure
> what would be the point of allowing the former and restricting the latter
> -- the horse is already out of the barn. Instead of
>
>   let rec fac = function
>     | 0 -> 1
>     | n -> n * fac (n - 1)
>
> I can write
>
>   let rec fac = function
>     | 0 -> 1
>     | n -> n * f (n - 1)
>   and f n = fac n
>
> turning any self-recursion into mutual-recursion.
>
> I'm not sure I understand your point about accidental value recursion. Do
> you have an example?
>
> Note that it is possible to use recursive modules as a way to have
> recursion between phrases (structure items) without explicitly using "rec".
> It's a bad idea in most situations, because using recursive modules makes
> you rely on more complex (and accordinly more fragile) features of the
> language.
>
> On Mon, Mar 2, 2015 at 7:25 AM, Jordan W <jordojw@gmail.com> wrote:
>
>> (Note: When trying any of these examples, make sure to kill/restart
>> your top level between each examples - non-recursive bindings that
>> should fail will appear to work because they use existing bindings in
>> the environment).
>>
>> My understanding is that self-recursion in OCaml is introduced via the
>> `let rec` binding keyword pair.
>>
>>     let rec x a = x a
>>
>>
>> A sequence of let bindings are made *both* mutually recursive, *and*
>> individually self-recursive via a combination of `let rec` and the
>> `and` keyword.
>>
>>    (* Notice how y is made self recursive as well *)
>>    let rec x a = (x a + y a) and y a = (x a + y a);;
>>
>> The `and` keyword by itself is not sufficient to introduce mutual
>> recursion, and not sufficient to introduce self-recursion for any of
>> the bindings joined by the `and`.
>>
>>     (* Does not work *)
>>     let x a = x a and y a = (x a + y a)
>>     (* Does not work *)
>>     let x a = y a and y a = x a
>>
>>
>> My questions are:
>> 1. Is there any effect to having the `and` keyword, without a `let
>> rec` that initiates the let binding sequence?
>> 2. Is there any way to introduce mutual recursion without also
>> introducing self-recursion on *all* of the bindings?
>>
>> I would like self-recursion to be independent from mutual recursion.
>> It would be nice to be able to create several mutually recursive
>> bindings that are not individually self-recursive. I imagine the
>> syntax to accomplish this would require each binding to be opened with
>> "let" or "let rec" which would be totally reasonable.
>>
>>     (* Three mutually recursive functions that are not self-recursive *)
>>     let rec thisOneIsSelfRecursive x = ... and
>>     let thisOneIsNotSelfRecursive y = ... and
>>     let rec thisOneIsAlsoSelfRecursive z = ...;
>>
>> This becomes more desirable when one of the mutually recursive
>> bindings is a non-function value that you did not want to make
>> self-recursive by accident (which causes cycles).
>>
>> Jordan
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa.inria.fr/sympa/arc/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
>
>

[-- Attachment #2: Type: text/html, Size: 5186 bytes --]