Erlang Recursive end loop

Question

I just started learning Erlang and since I found out there is no for loop I tried recreating one with recursion:

display(Rooms, In) ->
    Room = array:get(In, Rooms)
    io:format("~w", [Room]),
    if
        In < 59 -> display(Rooms, In + 1);
        true -> true
    end.

With this code i need to display the content (false or true) of each array in Rooms till the number 59 is reached. However this creates a weird code which displays all of Rooms contents about 60 times (?). When I drop the if statement and only put in the recursive code it is working except for a exception error: Bad Argument.

So basically my question is how do I put a proper end to my "for loop".

Thanks in advance!

Answer 1

Hmm, this code is rewritten and not pasted. It is missing colon after Room = array:get(In, Rooms). The Bad argument error is probably this:

exception error: bad argument
in function  array:get/2 (array.erl, line 633)
in call from your_module_name:display/2

This means, that you called array:get/2 with bad arguments: either Rooms is not an array or you used index out of range. The second one is more likely the cause. You are checking if:

In < 59

and then calling display again, so it will get to 58, evaluate to true and call:

display(Rooms, 59)

which is too much.

There is also couple of other things:

1. In io:format/2 it is usually better to use ~p instead of ~w. It does exactly the same, but with pretty printing, so it is easier to read.

2. In Erlang if is unnatural, because it evaluates guards and one of them has to match or you get error... It is just really weird.

case is much more readable:

case In < 59 of
    false -> do_something();
    true -> ok
end

In case you usually write something, that always matches:

case Something of
    {One, Two} -> do_stuff(One, Two);
    [Head, RestOfList] -> do_other_stuff(Head, RestOfList);
    _ -> none_of_the_previous_matched()
end

The underscore is really useful in pattern matching.

3. In functional languages you should never worry about details like indexes! Array module has map function, which takes function and array as arguments and calls the given function on each array element.

So you can write your code this way:

display(Rooms) ->
    DisplayRoom = fun(Index, Room) -> io:format("~p ~p~n", [Index, Room]) end,
    array:map(DisplayRoom, Rooms).

This isn't perfect though, because apart from calling the io:format/2 and displaying the contents, it will also construct new array. io:format returns atom ok after completion, so you will get array of 58 ok atoms. There is also array:foldl/3, which doesn't have that problem.

If you don't have to have random access, it would be best to simply use lists.

Rooms = lists:duplicate(58, false),
DisplayRoom = fun(Room) -> io:format("~p~n", [Room]) end,
lists:foreach(DisplayRoom, Rooms)

If you are not comfortable with higher order functions. Lists allow you to easily write recursive algorithms with function clauses:

display([]) ->                 % always start with base case, where you don't need recursion
    ok;                        % you have to return something
display([Room | RestRooms]) -> % pattern match on list splitting it to first element and tail
    io:format("~p~n", [Room]), % do something with first element
    display(RestRooms).        % recursive call on rest (RestRooms is quite funny name :D)

To summarize - don't write forloops in Erlang :)

Answer 2

This is a general misunderstanding of recursive loop definitions. What you are trying to check for is called the "base condition" or "base case". This is easiest to deal with by matching:

display(0, _) ->
    ok;
display(In, Rooms) ->
    Room = array:get(In, Rooms)
    io:format("~w~n", [Room]),
    display(In - 1, Rooms).

This is, however, rather unidiomatic. Instead of using a hand-made recursive function, something like a fold or map is more common.

Going a step beyond that, though, most folks would probably have chosen to represent the rooms as a set or list, and iterated over it using list operations. When hand-written the "base case" would be an empty list instead of a 0:

display([]) ->
    ok;
display([Room | Rooms]) ->
    io:format("~w~n", [Room]),
    display(Rooms).

Which would have been avoided in favor, once again, of a list operation like foreach:

display(Rooms) ->
    lists:foreach(fun(Room) -> io:format("~w~n", [Room]) end, Rooms).

Some folks really dislike reading lambdas in-line this way. (In this case I find it readable, but the larger they get the more likely the are to become genuinely distracting.) An alternative representation of the exact same function:

display(Rooms) ->
    Display = fun(Room) -> io:format("~w~n", [Room]) end,
    lists:foreach(Display, Rooms).

Which might itself be passed up in favor of using a list comprehension as a shorthand for iteration:

_ = [io:format("~w~n", [Room]) | Room <- Rooms].

When only trying to get a side effect, though, I really think that lists:foreach/2 is the best choice for semantic reasons.

I think part of the difficulty you are experiencing is that you have chosen to use a rather unusual structure as your base data for your first Erlang program that does anything (arrays are not used very often, and are not very idiomatic in functional languages). Try working with lists a bit first -- its not scary -- and some of the idioms and other code examples and general discussions about list processing and functional programming will make more sense.

Wait! There's more...

I didn't deal with the case where you have an irregular room layout. The assumption was always that everything was laid out in a nice even grid -- which is never the case when you get into the really interesting stuff (either because the map is irregular or because the topology is interesting).

The main difference here is that instead of simply carrying a list of [Room] where each Room value is a single value representing the Room's state, you would wrap the state value of the room in a tuple which also contained some extra data about that state such as its location or coordinates, name, etc. (You know, "metadata" -- which is such an overloaded, buzz-laden term today that I hate saying it.)

Let's say we need to maintain coordinates in a three-dimensional space in which the rooms reside, and that each room has a list of occupants. In the case of the array we would have divided the array by the dimensions of the layout. A 10*10*10 space would have an array index from 0 to 999, and each location would be found by an operation similar to

locate({X, Y, Z}) -> (1 * X) + (10 * Y) + (100 * Z).

and the value of each Room would be [Occupant1, occupant2, ...].

It would be a real annoyance to define such an array and then mark arbitrarily large regions of it as "unusable" to give the impression of irregular layout, and then work around that trying to simulate a 3D universe.

Instead we could use a list (or something like a list) to represent the set of rooms, but the Room value would now be a tuple: Room = {{X, Y, Z}, [Occupants]}. You may have an additional element (or ten!), like the "name" of the room or some other status information or whatever, but the coordinates are the most certain real identity you're likely to get. To get the room status you would do the same as before, but mark what element you are looking at:

display(Rooms) ->
    Display =
        fun({ID, Occupants}) ->
            io:format("ID ~p: Occupants ~p~n", [ID, Occupants])
        end,
    lists:foreach(Display, Rooms).

To do anything more interesting than printing sequentially, you could replace the internals of Display with a function that uses the coordinates to plot the room on a chart, check for empty or full lists of Occupants (use pattern matching, don't do it procedurally!), or whatever else you might dream up.