[erlang-questions] The If expression

Richard O'Keefe <>
Thu Apr 22 01:24:41 CEST 2010

On Apr 22, 2010, at 11:10 AM, Henning Diedrich wrote:

> Did anything come from the discussion about the if expression ( http://www.erlang.org/pipermail/erlang-questions/2009-January/040808.html 
>  )?

(1) The "undocumented?" comment in that article is just plain wrong.
     This is a property of all guards and is documented.

(2) As for
     if Expression -> Body  else -> ElseBody  end,

     (A) It is just _too_ confusing to have 'if <guard>' and
         'if <expression>' in the same language.

     (B) General Erlang "style" for 'else' is '; true ->'

     (C) It has been argued at great length over many years in the
         Software Engineering community that 'boolean' is almost always
         the wrong type to use.  In too many situations, it is not clear
         which convention is followed: does 'true' mean connected or
         disconnected?  In too many other situations, there are more  
         two possibilities.  In this mailing list, the latter case has
         very often been substantiated.

> I remember reading that one-branched ifs shouldn't be necessary.

(3) It's not that they SHOULDN'T be necessary.
     It's not even the obvious fact that they AREN'T necessary.
     The point is (2,C) that they are often WRONG.

> And that if they are needed it's a sign of bad structure / code in  
> the first place.

     Not "if they are NEEDED", because they never are.
     "If they are USED".

> Is there a specific tip on how to think differently when one runs  
> into frequently using one-armed ifs? I.e., writing a lot of true ->  
> nil for the empty second branch?

For one thing, this is a clear sign of writing imperative code.
Pure functional languages like Haskell and Clean don't have one-armed
ifs because every expression has to have a value, and both arms of an
if have to have values of the same type.

The best thing to do is to show us some code and invite us to refactor  

More information about the erlang-questions mailing list