If you have a recursive function that relies on some other function what is the preferred way to implement that?
1) outside the recursive function
let doSomething n = ...
let rec doSomethingElse x =
match x with
| yourDone -> ...
| yourNotDone -> doSomethingElse (doSomething x)
2) inside the recursive function
let rec doSomethingElse x =
let doSomething n = ...
match x with
| yourDone -> ...
| yourNotDone -> doSomethingElse (doSomething x)
3) encapsulate both inside the a third function
let doSomethingElse x =
let doSomething n = ...
let innerDoSomethingElse =
match x with
| yourDone -> ...
| yourNotDone -> innerDoSomethingElse (doSomething x)
4) something even better?
Recursion is orthogonal to side effects. You can have a recursive function with side effects, or without. You can also have a non-recursive function with side effects, or without. It's a matter of opinion and taste whether it's better to avoid side effects in any particular situation.
Recursive functions are functions that calls itself. It is always made up of 2 portions, the base case and the recursive case. The base case is the condition to stop the recursion. The recursive case is the part where the function calls on itself.
Recursive algorithms are often inefficient for small data, due to the overhead of repeated function calls and returns. For this reason efficient implementations of recursive algorithms often start with the recursive algorithm, but then switch to a different algorithm when the input becomes small.
The most-common cause of stack overflow is excessively deep or infinite recursion, in which a function calls itself so many times that the space needed to store the variables and information associated with each call is more than can fit on the stack.
module Test =
let f x =
let add a b = a + b //inner function
add x 1
let f2 x =
let add a = a + x //inner function with capture, i.e., closure
add x
let outerAdd a b = a + b
let f3 x =
outerAdd x 1
Translates to:
[CompilationMapping(SourceConstructFlags.Module)]
public static class Test {
public static int f(int x) {
FSharpFunc<int, FSharpFunc<int, int>> add = new add@4();
return FSharpFunc<int, int>.InvokeFast<int>(add, x, 1);
}
public static int f2(int x) {
FSharpFunc<int, int> add = new add@8-1(x);
return add.Invoke(x);
}
public static int f3(int x) {
return outerAdd(x, 1);
}
[CompilationArgumentCounts(new int[] { 1, 1 })]
public static int outerAdd(int a, int b) {
return (a + b);
}
[Serializable]
internal class add@4 : OptimizedClosures.FSharpFunc<int, int, int> {
internal add@4() { }
public override int Invoke(int a, int b) {
return (a + b);
}
}
[Serializable]
internal class add@8-1 : FSharpFunc<int, int> {
public int x;
internal add@8-1(int x) {
this.x = x;
}
public override int Invoke(int a) {
return (a + this.x);
}
}
}
The only additional cost for an inner function is new'ing up an instance of FSharpFunc
--seems negligible.
Unless you're very performance sensitive, I would go with the scope that makes the most sense, that is, the narrowest scope possible.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With