On 2/02/2015, at 8:02 pm, Roelof Wobben <r.wobben@REDACTED> wrote:
>
> Now Im doubt or looking for a erlang book which takes lesser steps and explain things like recursion in smaller steps or that Erlang is not the language for me.
The thing that is hardest to explain about recursion is that there is nothing to explain.
It isn't any harder to understand than iteration.
Let's take the task of removing N bottles of beer from the wall.
If N = 0, there is nothing left to do.
If N > 0, there is a first bottle of beer to remove,
and then there are N-1 bottles to remove
and the trick for BOTH iteration and recursion is that you
get to do "remove N-1 bottles" with the *same* "remove N bottles"
code that you are writing.
Using familiar notation for loops:
N = 99;
while (!(N == 0)) { /* while not stopping */
remove_first_bottle();
N--;
/* Play it again, Sam! */
}
Using recursion:
long_song(99)
where
long_song(0) -> % stopping
ok;
long_song(N) ->
remove_first_bottle(),
long_song(N-1). % Play it again, Sam!
In both cases, you have to sort out:
- How do you know when to stop?
- What are you going to do when you stop?
- How do you know when to keep going?
- What are you going to do in the body of the
loop/recursive case?
- What is it that gets smaller on each "iteration"?
In this example, it's
- Stop when N = 0
- Do nothing in that case
- Continue when N > 0 (not explicitly tested)
- Remove one bottle
- N gets smaller; eventually it reaches 0 and we stop.
Now the thing that is *really* tricky here is that while
loops come with an absurd and arbitrary restriction.
You can only do "the remaining iterations" *after* you
have done the current iteration. But why not do it
like this:
If N = 0, there is nothing left to do.
If N > 0, remove N - 1 bottles and then
remove any remaining bottle.
Or
long_song(0) ->
ok;
long_song(N) ->
long_song(N-1),
remove_any_bottle().
Iteration is just a bizarrely restricted special case of
recursion. In both cases the essential idea is to handle
an arbitrary number of steps with ONE piece of code that
somehow (by explcit call or implicit jump) re-enters itself,
so that *one* form handles *any* number of things. In both
cases, you have to make sure that some measure of the
problem size (the length of a list, the number of things
left to work on, the size of a tree, whatever) is strictly
smaller every time you go around again.
Really, except for a few minor syntax issues, none of the
problems you have been having really have anything to do
with Erlang.
Possibly THE major problem you are having is not starting
by clearly grasping the problem and writing down your
understanding as comments. If what I am about to write
seems nasty to you, I apologise, but here it is: it looks
as though you are trying to solve programming problems by
hacking away at them in the hopes that they will eventually
succumb, instead of starting by trying to analyse them
clearly. That approach is not going to get you far with
any programming language.
If you are having trouble with recursion, then make tracks
NOW for a copy of The Little Schemer.