I imagine it compiles down to something similar either way, but its good to know you don’t have to take a performance hit.

run(N)->
error_logger:info_report(timer:tc(?MODULE,loop_fun,[N])),
error_logger:info_report(timer:tc(?MODULE,loop_case,[N])).

is_even(I)->
I rem 2 == 0.

loop_case(0)->
finish;
loop_case(N)->
case_it(N,is_even(N)).

case_it(N,Boolean)->
case Boolean of
true->
loop_case(N-1);
false->
loop_case(N-1)
end.

loop_fun(0)->
finish;
loop_fun(N)->
fun_it(N,is_even(N)).

fun_it(N,true)->
loop_fun(N-1);
fun_it(N,false)->
loop_fun(N-1).

Results

36> speed:run(10000000).

=INFO REPORT==== 14-May-2009::15:51:36 ===
{1484000,finish}
ok

=INFO REPORT==== 14-May-2009::15:51:38 ===
{1390999,finish}
37>

Seems like no difference:)

Agreed, I think if/case statements are soft of an afterthought for erlang, which is fine with me. I think R. Virding wrote something like this on his blog.

operation(Thing) ->
% something funky which binds Result
Result.

something([], Accum) ->
Accum;

something([Next | Rest], Accum) ->
something(Rest, operation(Next)).

To me, that reads: `something` will return Accum if the first parameter is an empty list, `something` will operate and recurse if there’s an element to be used. I can read the purpose of the function by reading its definition, instead of delving into its guts.

Kudos.

The more I look at it the more I’m starting to agree with you. Personal preference to a point I guess.

I should probably finish the software before bothering with stuff like this though eh?

That additional formatting is all I can think of to make it easier to read. A quick glance at that function is easier to understand than tracing through head matching functions, imho.

but as you said, the case is less syntax. If you can do the same function, with less to type, and without losing clarity, go for it.

It might be less syntax for the case statement, but I think Erlangs case/if statements are sort of clunky. That’s the only reason I can come up with for why I like using the head matching.