Expressions

In this chapter, all valid Erlang expressions are listed. When writing Erlang programs, it is also allowed to use macro- and record expressions. However, these expressions are expanded during compilation and are in that sense not true Erlang expressions. Macro- and record expressions are covered in separate chapters: Macros and Records.

6.1 Expression Evaluation

All subexpressions are evaluated before an expression itself is evaluated, unless explicitly stated otherwise. For example, consider the expression:

Expr1 + Expr2

Expr1 and Expr2, which are also expressions, are evaluated first - in any order - before the addition is performed.

Many of the operators can only be applied to arguments of a certain type. For example, arithmetic operators can only be applied to numbers. An argument of the wrong type will cause a badarg run-time error.

6.2 Terms

The simplest form of expression is a term, that is an integer, float, atom, string, list or tuple. The return value is the term itself.

6.3 Variables

A variable is an expression. If a variable is bound to a value, the return value is this value. Unbound variables are only allowed in patterns.

Variables start with an uppercase letter or underscore (_) and may contain alphanumeric characters, underscore and @. Examples:

X
Name1
PhoneNumber
Phone_number
_
_Height

Variables are bound to values using pattern matching. Erlang uses single assignment, a variable can only be bound once.

The anonymous variable is denoted by underscore (_) and can be used when a variable is required but its value can be ignored. Example:

[H|_] = [1,2,3]

Variables starting with underscore (_), for example _Height, are normal variables, not anonymous. They are however ignored by the compiler in the sense that they will not generate any warnings for unused variables. Example: The following code

member(_, []) ->
    [].

member(Elem, []) ->
    [].

This will however cause a warning for an unused variable Elem, if the code is compiled with the flag warn_unused_vars set. Instead, the code can be rewritten to:

member(_Elem, []) ->
    [].

Note that since variables starting with an underscore are not anonymous, this will match:

{_,_} = {1,2}

{_N,_N} = {1,2}

The scope for a variable is its function clause. Variables bound in a branch of an if, case, or receive expression must be bound in all branches to have a value outside the expression, otherwise they will be regarded as 'unsafe' outside the expression.

For the try expression introduced in Erlang 5.4/OTP-R10B, variable scoping is limited so that variables bound in the expression are always 'unsafe' outside the expression. This will be improved.

6.4 Patterns

A pattern has the same structure as a term but may contain unbound variables. Example:

Name1
[H|T]
{error,Reason}

Patterns are allowed in clause heads, case and receive expressions, and match expressions.

6.4.1 Match Operator = in Patterns

If Pattern1 and Pattern2 are valid patterns, then the following is also a valid pattern:

Pattern1 = Pattern2

When matched against a term, both Pattern1 and Pattern2 will be matched against the term. The idea behind this feature is to avoid reconstruction of terms. Example:

f({connect,From,To,Number,Options}, To) ->
    Signal = {connect,From,To,Number,Options},
    ...;
f(Signal, To) ->
    ignore.

f({connect,_,To,_,_} = Signal, To) ->
    ...;
f(Signal, To) ->
    ignore.

6.4.2 String Prefix in Patterns

f("prefix" ++ Str) -> ...

f([$p,$r,$e,$f,$i,$x | Str]) -> ...

6.4.3 Expressions in Patterns

An arithmetic expression can be used within a pattern, if it uses only numeric or bitwise operators, and if its value can be evaluated to a constant at compile-time. Example:

case {Value, Result} of
    {?THRESHOLD+1, ok} -> ...

6.5 Match

Expr1 = Expr2

Matches Expr1, a pattern, against Expr2. If the matching succeeds, any unbound variable in the pattern becomes bound and the value of Expr2 is returned.

1> {A, B} = {answer, 42}.
{answer,42}
2> A.
answer
3> {C, D} = [1, 2].
** exception error: no match of right hand side value [1,2]

6.6 Function Calls

ExprF(Expr1,...,ExprN)
ExprM:ExprF(Expr1,...,ExprN)

In the first form of function calls, ExprM:ExprF(Expr1,...,ExprN), each of ExprM and ExprF must be an atom or an expression that evaluates to an atom. The function is said to be called by using the fully qualified function name. This is often referred to as a remote or external function call. Example:

lists:keysearch(Name, 1, List)

In the second form of function calls, ExprF(Expr1,...,ExprN), ExprF must be an atom or evaluate to a fun.

If ExprF is an atom the function is said to be called by using the implicitly qualified function name. If ExprF/N is the name of a function explicitly or automatically imported from module M, then the call is short for M:ExprF(Expr1,...,ExprN). Otherwise, ExprF/N must be a locally defined function. Examples:

handle(Msg, State)
spawn(m, init, [])

Fun1 = fun(X) -> X+1 end
Fun1(3)
=> 4

Fun2 = {lists,append}
Fun2([1,2], [3,4])
=> [1,2,3,4]

fun lists:append/2([1,2], [3,4])
=> [1,2,3,4]

To avoid possible ambiguities, the fully qualified function name must be used when calling a function with the same name as a BIF, and the compiler does not allow defining a function with the same name as an explicitly imported function.

Note that when calling a local function, there is a difference between using the implicitly or fully qualified function name, as the latter always refers to the latest version of the module. See Compilation and Code Loading.

6.7 If

if
    GuardSeq1 ->
        Body1;
    ...;
    GuardSeqN ->
        BodyN
end

The branches of an if-expression are scanned sequentially until a guard sequence GuardSeq which evaluates to true is found. Then the corresponding Body (sequence of expressions separated by ',') is evaluated.

If no guard sequence is true, an if_clause run-time error will occur. If necessary, the guard expression true can be used in the last branch, as that guard sequence is always true.

is_greater_than(X, Y) ->
    if
        X>Y ->
            true;
        true -> % works as an 'else' branch
            false
    end

6.8 Case

case Expr of
    Pattern1 [when GuardSeq1] ->
        Body1;
    ...;
    PatternN [when GuardSeqN] ->
        BodyN
end

The expression Expr is evaluated and the patterns Pattern are sequentially matched against the result. If a match succeeds and the optional guard sequence GuardSeq is true, the corresponding Body is evaluated.

If there is no matching pattern with a true guard sequence, a case_clause run-time error will occur.

is_valid_signal(Signal) ->
    case Signal of
        {signal, _What, _From, _To} ->
            true;
        {signal, _What, _To} ->
            true;
        _Else ->
            false
    end.

6.9 Send

Expr1 ! Expr2

Sends the value of Expr2 as a message to the process specified by Expr1. The value of Expr2 is also the return value of the expression.

Expr1 must evaluate to a pid, a registered name (atom) or a tuple {Name,Node}, where Name is an atom and Node a node name, also an atom.

6.10 Receive

receive
    Pattern1 [when GuardSeq1] ->
        Body1;
    ...;
    PatternN [when GuardSeqN] ->
        BodyN
end

Receives messages sent to the process using the send operator (!). The patterns Pattern are sequentially matched against the first message in time order in the mailbox, then the second, and so on. If a match succeeds and the optional guard sequence GuardSeq is true, the corresponding Body is evaluated. The matching message is consumed, that is removed from the mailbox, while any other messages in the mailbox remain unchanged.

receive never fails. Execution is suspended, possibly indefinitely, until a message arrives that does match one of the patterns and with a true guard sequence.

wait_for_onhook() ->
    receive
        onhook ->
            disconnect(),
            idle();
        {connect, B} ->
            B ! {busy, self()},
            wait_for_onhook()
    end.

receive
    Pattern1 [when GuardSeq1] ->
        Body1;
    ...;
    PatternN [when GuardSeqN] ->
        BodyN
after
    ExprT ->
        BodyT
end

ExprT should evaluate to an integer. The highest allowed value is 16#ffffffff, that is, the value must fit in 32 bits. receive..after works exactly as receive, except that if no matching message has arrived within ExprT milliseconds, then BodyT is evaluated instead and its return value becomes the return value of the receive..after expression.

wait_for_onhook() ->
    receive
        onhook ->
            disconnect(),
            idle();
        {connect, B} ->
            B ! {busy, self()},
            wait_for_onhook()
    after
        60000 ->
            disconnect(),
            error()
    end.

receive
after
    ExprT ->
        BodyT
end

This construction will not consume any messages, only suspend execution in the process for ExprT milliseconds and can be used to implement simple timers.

timer() ->
    spawn(m, timer, [self()]).

timer(Pid) ->
    receive
    after
        5000 ->
            Pid ! timeout
    end.

6.11 Term Comparisons

Expr1 op Expr2

*Term Comparison Operators.*
op	Description
==	equal to
/=	not equal to
=<	less than or equal to
<	less than
>=	greater than or equal to
>	greater than
=:=	exactly equal to
=/=	exactly not equal to

number < atom < reference < fun < port < pid < tuple < list < bit string

Lists are compared element by element. Tuples are ordered by size, two tuples with the same size are compared element by element.

If one of the compared terms is an integer and the other a float, the integer is first converted into a float, unless the operator is one of =:= and =/=. If the integer is too big to fit in a float no conversion is done, but the order is determined by inspecting the sign of the numbers.

1> 1==1.0.
true
2> 1=:=1.0.
false
3> 1 > a.
false

6.12 Arithmetic Expressions

op Expr
Expr1 op Expr2

*Arithmetic Operators.*
op	Description	Argument type
+	unary +	number
-	unary -	number
+		number
-		number
*		number
/	floating point division	number
bnot	unary bitwise not	integer
div	integer division	integer
rem	integer remainder of X/Y	integer
band	bitwise and	integer
bor	bitwise or	integer
bxor	arithmetic bitwise xor	integer
bsl	arithmetic bitshift left	integer
bsr	bitshift right	integer

1> +1.
1
2> -1.
-1
3> 1+1.
2
4> 4/2.
2.00000
5> 5 div 2.
2
6> 5 rem 2.
1
7> 2#10 band 2#01.
0
8> 2#10 bor 2#01.
3

6.13 Boolean Expressions

op Expr
Expr1 op Expr2

*Logical Operators.*
op	Description
not	unary logical not
and	logical and
or	logical or
xor	logical xor

1> not true.
false
2> true and false.
false
3> true xor false.
true

6.14 Short-Circuit Boolean Expressions

Expr1 orelse Expr2
Expr1 andalso Expr2

Boolean expressions where Expr2 is evaluated only if necessary. That is, Expr2 is evaluated only if Expr1 evaluates to false in an orelse expression, or only if Expr1 evaluates to true in an andalso expression. Returns the Boolean value of the expression, that is true or false.

As of Erlang 5.5/OTP R11B, short-circuit boolean expressions are allowed in guards. In guards, however, evaluation is always short-circuited since guard tests are known to be free of side effects.

case A >= -1.0 andalso math:sqrt(A+1) > B of

This will work even if A is less than -1.0, since in that case, math:sqrt/1 is never evaluated.

OnlyOne = is_atom(L) orelse
         (is_list(L) andalso length(L) == 1),

6.15 List Operations

Expr1 ++ Expr2
Expr1 -- Expr2

The list concatenation operator ++ appends its second argument to its first and returns the resulting list.

The list subtraction operator -- produces a list which is a copy of the first argument, subjected to the following procedure: for each element in the second argument, the first occurrence of this element (if any) is removed.

1> [1,2,3]++[4,5].
[1,2,3,4,5]
2> [1,2,3,2,1,2]--[2,1,2].
[3,1,2]

6.16 Bit Syntax Expressions

<<>>
<<E1,...,En>>

Each element Ei specifies a segment of the bit string. Each element Ei is a value, followed by an optional size expression and an optional type specifier list.

Ei = Value |
     Value:Size |
     Value/TypeSpecifierList |
     Value:Size/TypeSpecifierList

Used in a bit string construction, Value is an expression which should evaluate to an integer, float or bit string. If the expression is something else than a single literal or variable, it should be enclosed in parenthesis.

Used in a bit string matching, Value must be a variable, or an integer, float or string.

Note that, for example, using a string literal as in <<"abc">> is syntactic sugar for <<$a,$b,$c>>.

Used in a bit string matching, Size must be an integer, or a variable bound to an integer.

The value of Size specifies the size of the segment in units (see below). The default value depends on the type (see below). For integer it is 8, for float it is 64, for binary and bitstring it is the whole binary or bit string. In matching, this default value is only valid for the very last element. All other bit string or binary elements in the matching must have a size specification.

TypeSpecifierList is a list of type specifiers, in any order, separated by hyphens (-). Default values are used for any omitted type specifiers.

The value of Size multiplied with the unit gives the number of bits. A segment of type binary must have a size that is evenly divisible by 8.

1> Bin1 = <<1,17,42>>.
<<1,17,42>>
2> Bin2 = <<"abc">>.
<<97,98,99>>
3> Bin3 = <<1,17,42:16>>.
<<1,17,0,42>>
4> <<A,B,C:16>> = <<1,17,42:16>>.
<<1,17,0,42>>
5> C.
42
6> <<D:16,E,F>> = <<1,17,42:16>>.
<<1,17,0,42>>
7> D.
273
8> F.
42
9> <<G,H/binary>> = <<1,17,42:16>>.
<<1,17,0,42>>
10> H.
<<17,0,42>>
11> <<G,H/bitstring>> = <<1,17,42:12>>.
<<1,17,1,10:4>>
12> H.
<<17,1,10:4>>

Note also that "B=<<1>>" is interpreted as "B =<<1>>" which is a syntax error. The correct way is to write a space after '=': "B= <<1>>.

6.17 Fun Expressions

fun
    (Pattern11,...,Pattern1N) [when GuardSeq1] ->
        Body1;
    ...;
    (PatternK1,...,PatternKN) [when GuardSeqK] ->
        BodyK
end

A fun expression begins with the keyword fun and ends with the keyword end. Between them should be a function declaration, similar to a regular function declaration, except that no function name is specified.

Variables in a fun head shadow variables in the function clause surrounding the fun expression, and variables bound in a fun body are local to the fun body.

1> Fun1 = fun (X) -> X+1 end.
#Fun<erl_eval.6.39074546>
2> Fun1(2).
3
3> Fun2 = fun (X) when X>=5 -> gt; (X) -> lt end.
#Fun<erl_eval.6.39074546>
4> Fun2(7).
gt

fun Name/Arity
fun Module:Name/Arity

In Name/Arity, Name is an atom and Arity is an integer. Name/Arity must specify an existing local function. The expression is syntactic sugar for:

fun (Arg1,...,ArgN) -> Name(Arg1,...,ArgN) end

In Module:Name/Arity, Module and Name are atoms and Arity is an integer. A fun defined in this way will refer to the function Name with arity Arity in the latest version of module Module.

When applied to a number N of arguments, a tuple {Module,FunctionName} is interpreted as a fun, referring to the function FunctionName with arity N in the module Module. The function must be exported. This usage is deprecated. See Function Calls for an example.

6.18 Catch and Throw

catch Expr

Returns the value of Expr unless an exception occurs during the evaluation. In that case, the exception is caught. For exceptions of class error, that is run-time errors: {'EXIT',{Reason,Stack}} is returned. For exceptions of class exit, that is the code called exit(Term): {'EXIT',Term} is returned. For exceptions of class throw, that is the code called throw(Term): Term is returned.

Reason depends on the type of error that occurred, and Stack is the stack of recent function calls, see Errors and Error Handling.

1> catch 1+2.
3
2> catch 1+a.
{'EXIT',{badarith,[...]}}

Note that catch has low precedence and catch subexpressions often needs to be enclosed in a block expression or in parenthesis:

3> A = catch 1+2.
** 1: syntax error before: 'catch' **
4> A = (catch 1+2).
3

The BIF throw(Any) can be used for non-local return from a function. It must be evaluated within a catch, which will return the value Any. Example:

5> catch throw(hello).
hello

If throw/1 is not evaluated within a catch, a nocatch run-time error will occur.

6.19 Try

try Exprs
catch
    [Class1:]ExceptionPattern1 [when ExceptionGuardSeq1] ->
        ExceptionBody1;
    [ClassN:]ExceptionPatternN [when ExceptionGuardSeqN] ->
        ExceptionBodyN
end

This is an enhancement of catch that appeared in Erlang 5.4/OTP-R10B. It gives the possibility do distinguish between different exception classes, and to choose to handle only the desired ones, passing the others on to an enclosing try or catch or to default error handling.

Note that although the keyword catch is used in the try expression, there is not a catch expression within the try expression.

Returns the value of Exprs (a sequence of expressions Expr1, ..., ExprN) unless an exception occurs during the evaluation. In that case the exception is caught and the patterns ExceptionPattern with the right exception class Class are sequentially matched against the caught exception. An omitted Class is shorthand for throw. If a match succeeds and the optional guard sequence ExceptionGuardSeq is true, the corresponding ExceptionBody is evaluated to become the return value.

If an exception occurs during evaluation of Exprs but there is no matching ExceptionPattern of the right Class with a true guard sequence, the exception is passed on as if Exprs had not been enclosed in a try expression.

try Exprs of
    Pattern1 [when GuardSeq1] ->
        Body1;
    ...;
    PatternN [when GuardSeqN] ->
        BodyN
catch
    [Class1:]ExceptionPattern1 [when ExceptionGuardSeq1] ->
        ExceptionBody1;
    ...;
    [ClassN:]ExceptionPatternN [when ExceptionGuardSeqN] ->
        ExceptionBodyN
end

If the evaluation of Exprs succeeds without an exception, the patterns Pattern are sequentially matched against the result in the same way as for a case expression, except that if the matching fails, a try_clause run-time error will occur.

The try expression can also be augmented with an after section, intended to be used for cleanup with side effects:

try Exprs of
    Pattern1 [when GuardSeq1] ->
        Body1;
    ...;
    PatternN [when GuardSeqN] ->
        BodyN
catch
    [Class1:]ExceptionPattern1 [when ExceptionGuardSeq1] ->
        ExceptionBody1;
    ...;
    [ClassN:]ExceptionPatternN [when ExceptionGuardSeqN] ->
        ExceptionBodyN
after
    AfterBody
end

AfterBody is evaluated after either Body or ExceptionBody no matter which one. The evaluated value of AfterBody is lost; the return value of the try expression is the same with an after section as without.

Even if an exception occurs during evaluation of Body or ExceptionBody, AfterBody is evaluated. In this case the exception is passed on after AfterBody has been evaluated, so the exception from the try expression is the same with an after section as without.

If an exception occurs during evaluation of AfterBody itself it is not caught, so if AfterBody is evaluated after an exception in Exprs, Body or ExceptionBody, that exception is lost and masked by the exception in AfterBody.

The of, catch and after sections are all optional, as long as there is at least a catch or an after section, so the following are valid try expressions:

try Exprs of 
    Pattern when GuardSeq -> 
        Body 
after 
    AfterBody 
end

try Exprs
catch 
    ExpressionPattern -> 
        ExpressionBody
after
    AfterBody
end

try Exprs after AfterBody end

Example of using after, this code will close the file even in the event of exceptions in file:read/2 or in binary_to_term/1, and exceptions will be the same as without the try...after...end expression:

termize_file(Name) ->
    {ok,F} = file:open(Name, [read,binary]),
    try
        {ok,Bin} = file:read(F, 1024*1024),
        binary_to_term(Bin)
    after
        file:close(F)
    end.

try Expr
catch
    throw:Term -> Term;
    exit:Reason -> {'EXIT',Reason}
    error:Reason -> {'EXIT',{Reason,erlang:get_stacktrace()}}
end

6.20 Parenthesized Expressions

(Expr)

Parenthesized expressions are useful to override operator precedences, for example in arithmetic expressions:

1> 1 + 2 * 3.
7
2> (1 + 2) * 3.
9

6.21 Block Expressions

begin
   Expr1,
   ...,
   ExprN
end

Block expressions provide a way to group a sequence of expressions, similar to a clause body. The return value is the value of the last expression ExprN.

6.22 List Comprehensions

List comprehensions are a feature of many modern functional programming languages. Subject to certain rules, they provide a succinct notation for generating elements in a list.

List comprehensions are analogous to set comprehensions in Zermelo-Frankel set theory and are called ZF expressions in Miranda. They are analogous to the setof and findall predicates in Prolog.

[Expr || Qualifier1,...,QualifierN]

Expr is an arbitrary expression, and each Qualifier is either a generator or a filter.

The variables in the generator patterns shadow variables in the function clause surrounding the list comprehensions.

A list comprehension returns a list, where the elements are the result of evaluating Expr for each combination of generator list elements and bit string generator elements for which all filters are true.

1> [X*2 || X <- [1,2,3]].
[2,4,6]

6.23 Bit String Comprehensions

Bit string comprehensions are analogous to List Comprehensions. They are used to generate bit strings efficiently and succinctly.

<< BitString || Qualifier1,...,QualifierN >>

BitString is a bit string expression, and each Qualifier is either a generator, a bit string generator or a filter.

The variables in the generator patterns shadow variables in the function clause surrounding the bit string comprehensions.

A bit string comprehension returns a bit string, which is created by concatenating the results of evaluating BitString for each combination of bit string generator elements for which all filters are true.

1> << << (X*2) >> || 
<<X>> <= << 1,2,3 >> >>.
<<2,4,6>>

6.24 Guard Sequences

A guard sequence is a sequence of guards, separated by semicolon (;). The guard sequence is true if at least one of the guards is true.
Guard1;...;GuardK

A guard is a sequence of guard expressions, separated by comma (,). The guard is true if all guard expressions evaluate to true.
GuardExpr1,...,GuardExprN

The set of valid guard expressions (sometimes called guard tests) is a subset of the set of valid Erlang expressions. The reason for restricting the set of valid expressions is that evaluation of a guard expression must be guaranteed to be free of side effects. Valid guard expressions are:

*Type Test BIFs.*
is_atom/1
is_binary/1
is_constant/1
is_float/1
is_function/1
is_function/2
is_integer/1
is_list/1
is_number/1
is_pid/1
is_port/1
is_reference/1
is_tuple/1
is_record/2
is_record/3

Note that each type test BIF has an older equivalent, without the is_ prefix. These old BIFs are retained for backwards compatibility only and should not be used in new code. They are also only allowed at top level. For example, they are not allowed in boolean expressions in guards.

6.25 Operator Precedence

When evaluating an expression, the operator with the highest priority is evaluated first. Operators with the same priority are evaluated according to their associativity. Example: The left associative arithmetic operators are evaluated left to right:

*Other BIFs Allowed in Guard Expressions.*
abs(Number)
element(N, Tuple)
float(Term)
hd(List)
length(List)
node()
node(Pid\|Ref\|Port)
round(Number)
self()
size(Tuple\|Binary)
tl(List)
trunc(Number)

*Operator Precedence.*
:
#
Unary + - bnot not
/ * div rem band and	Left associative
+ - bor bxor bsl bsr or xor	Left associative
++ --	Right associative
== /= =< < >= > =:= =/=	-
andalso
orelse
= !	Right associative
catch

6 + 5 * 4 - 3 / 2 evaluates to
6 + 20 - 1.5 evaluates to
26 - 1.5 evaluates to
24.5

6 Expressions